[cairo] XShm

[Chris Wilson]

Vladimir Vukicevic (vladimir at pobox.com) said: 
> 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.
The initial stab at an API was to try to address Cairo's internal need to
create images for uploading to the backend, e.g. gradients and loading of
PNG data.
 
> 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_t *
> 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).

cairo_surface_as_image() is quite appealing (at least for the pixel
based surfaces), but one quickly runs into complexities synchronizing
the pixels between the image and the Xserver.

Perhaps something akin to push_group/pop_group:
    cairo_acquire_image (cr); /* wraps acquire_dest_image() & redirection */
    /* get pixel data for direct manipulation */
    bits = cairo_image_surface_get_data (cairo_get_target (cr));
    /* ... */
    cairo_release_image (cr); /* release_dest_image() & restore */

This would be for surfaces like win32 virtually a no-op and hit the XShm
path for xlib.

Vlad, could you give some insight as to how
cairo_win32_surface_get_image() is used by applications?
--
Chris Wilson