vladimir at pobox.com
Thu Oct 18 19:55:06 PDT 2007
Chris Wilson wrote:
> Using XShm for transferring the images between Cairo and the Xserver
> seems like a sensible performance optimization and one that interests
> quite a few people. The nasty part is that in order to avoid copying the
> image data, the shared memory segment must be constructed upon image
> create and the image's pixels allocated from within the shared memory.
> To allow the higher levels and application code to construct XShm-based
> cairo_image_surface_t, we add a new function
> cairo_image_surface_create_for_target() that purports to create an image
> optimized for future use with the target backend.
Hey Chris, great work! Some comments about the API.... For some
surfaces, it's easy to create an image surface that points to the same
data. For example, when the win32 backend creates a specific win32
object, it has direct access to the bits -- it can then create an image
surface with the right data pointer etc. for direct access there. The
API doesn't seem to cover that; that is, cairo_image_surface_create_*
always needs to create a new surface.
However, your API does make it possible to write more generic code for
loading. So while you're adding backend API, maybe adding something like...
cairo_surface_get_as_image (cairo_surface_t *other);
that returns either a cairo image surface that points to the same bits
as 'other', or returns an error surface. That way, surfaces could
support both ways of fast loading of bits (or other poking at the raw data).
More information about the cairo