1. 13 Aug, 2011 1 commit
  2. 26 Jul, 2011 1 commit
    • Chris Wilson's avatar
      API: map-to-image and create-similar-image · a69335a8
      Chris Wilson authored
      
      
      A common requirement is the fast upload of pixel data. In order to
      allocate the most appropriate image buffer, we need knowledge of the
      destination. The most obvious example is that we could use a
      shared-memory region for the image to avoid the transfer cost of
      uploading the pixels to the X server. Similarly, gl, win32, quartz...
      
      The other side of the equation is that for manual modification of a
      remote surface, it would be more efficient if we can create a similar
      image to reduce the transfer costs. This strategy is already followed
      for the destination fallbacks and this merely exposes the same
      capability for the application fallbacks.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      a69335a8
  3. 15 Jul, 2011 1 commit
    • Chris Wilson's avatar
      Implement cairo_backend_t · 83bfd85a
      Chris Wilson authored
      
      
      Allow a backend to completely reimplement the Cairo API as it wants. The
      goal is to pass operations to the native backends such as Quartz,
      Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
      logging contexts, and whatever else the imagination holds. Perhaps to
      experiment with double-paths?
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      83bfd85a
  4. 30 Apr, 2010 2 commits
  5. 28 Apr, 2010 2 commits
  6. 27 Apr, 2010 2 commits
  7. 15 Apr, 2010 1 commit
  8. 24 Mar, 2010 1 commit
  9. 22 Mar, 2010 1 commit
  10. 22 Jan, 2010 2 commits
    • Chris Wilson's avatar
      Add cairo_device_t · f617d5fc
      Chris Wilson authored
      The device is a generic method for accessing the underlying interface
      with the native graphics subsystem, typically the X connection or
      perhaps the GL context. By exposing a cairo_device_t on a surface and
      its various methods we enable finer control over interoperability with
      external interactions of the device by applications. The use case in
      mind is, for example, a multi-threaded gstreamer which needs to serialise
      its own direct access to the device along with Cairo's across many
      threads.
      
      Secondly, the cairo_device_t is a unifying API for the mismash of
      backend specific methods for controlling creation of surfaces with
      explicit devices and a convenient hook for debugging and introspection.
      
      The principal components of the API are the memory management of:
      
        cairo_device_reference(),
        cairo_device_finish() and
        cairo_device_destroy();
      
      along with a pair of routines for serialising interaction:
      
        cairo_device_acquire() and
        cairo_device_release()
      
      and a method to flush any outstanding accesses:
      
        cairo_device_flush().
      
      The device for a particular surface may be retrieved using:
      
        cairo_surface_get_device().
      
      The device returned is owned by the surface.
      f617d5fc
    • Chris Wilson's avatar
      Real zero-copy cow snapshotting · 934d0d0d
      Chris Wilson authored
      The first iteration of COW snapshotting always made an initial copy when
      the snapshot was requested (and reused that copy until the surface was
      modified). However, in a few circumstances we can avoid even that copy
      so long as the surface is still alive and unmodified between the
      snapshotting and its use. In order to do so, we need a new proxy surface
      that can automatically perform the copy if the target should disappear
      prior to use.
      934d0d0d