1. 09 Feb, 2012 1 commit
  2. 12 Sep, 2011 1 commit
    • Chris Wilson's avatar
      Introduce a new compositor architecture · af9fbd17
      Chris Wilson authored
      
      
      Having spent the last dev cycle looking at how we could specialize the
      compositors for various backends, we once again look for the
      commonalities in order to reduce the duplication. In part this is
      motivated by the idea that spans is a good interface for both the
      existent GL backend and pixman, and so they deserve a dedicated
      compositor. xcb/xlib target an identical rendering system and so they
      should be using the same compositor, and it should be possible to run
      that same compositor locally against pixman to generate reference tests.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      
      P.S. This brings massive upheaval (read breakage) I've tried delaying in
      order to fix as many things as possible but now this one patch does far,
      far, far too much. Apologies in advance for breaking your favourite
      backend, but trust me in that the end result will be much better. :)
      af9fbd17
  3. 14 Aug, 2011 4 commits
  4. 13 Aug, 2011 1 commit
  5. 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
  6. 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
  7. 30 Apr, 2010 2 commits
  8. 28 Apr, 2010 2 commits
  9. 27 Apr, 2010 2 commits
  10. 15 Apr, 2010 1 commit
  11. 24 Mar, 2010 1 commit
  12. 22 Mar, 2010 1 commit
  13. 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