chris at chris-wilson.co.uk
Fri Oct 19 03:15:22 PDT 2007
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
> 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?
More information about the cairo