[cairo] XShm

[Benjamin Otte]

Behdad Esfahbod <behdad <at> behdad.org> writes:

> Should we stand back and have a look at the big picture again?  What is
> the concrete problem we are trying to solve?  Loading JPG/PNG images?
> If that's the case, given that we need some way to pass in original
> image data to cairo for acceptable PDF embedding, maybe we can focus on
> such API instead, and make it use XShm internally for the xlib
> implementation.
> 
Here's the big picture from Swfdec's POV:

Swfdec needs a way to hand image data to Cairo. Images come in a variety of
sorts: as static images (JPEG, GIF or PNG) or as part of a video stream. The
data pretty much gets decoded to on of these 3 formats: I420 YUV, RGB or RGBA.
After the image data has been created, the image can be modified. GIF and some
video decoders can do this. But most of these don't expose this functionality in
their API, so the ability to modify is of no immediate benefit to Swfdec.
Creating the image might have some constraints. For example GStreamer wants a
rowstride that's a multiple of 32bits and (at least for YUV) rounds up image
sizes to an even number, even thought the actual image is odd. So I'd need the
ability to have a width/height that differs from the allocated rowstride/height.
FFmpeg additionally requires an 32/64bit aligned memory region to not crash with
their MMX/SSE optimizations. 

An pretty ideal API for me would look something like this:
mem = cairo_image_memory_allocate (size, alignment);
// render image
cairo_image_surface_new_from_memory (mem, format, width, height, rowstride);

Notes:
- format would include I420 YUV for video or jpeg data.
- the memory pointed to by mem would probably be invalid after the call to
_new_from_memory()

Cheers,
Benjamin