[cairo] XShm

[Vladimir Vukicevic]

On Oct 29, 2007, at 8:27 PM, Behdad Esfahbod wrote:

> On Fri, 2007-10-26 at 13:50 -0400, Chris Wilson wrote:
>
>> Of note, it turns out that cairo_image_surface_create_similar() has
>> one or two subtle flaws - the first being that no-one can agree on an
>> appropriate name that does not cause confusion for the language
>> bindings. The second is that it exposes the user to ugly
>> synchronization problems when using it as a source for the xlib  
>> backend,
>> i.e. if the user does not call XSync() or otherwise guarantee that  
>> they
>> will not modify the data before the xserver has finished using it,  
>> then
>> they will corrupt the output. In practise, the interface is still  
>> useful
>> for zero-copy loading of image data, but breaks if reused (for  
>> example
>> rendering each frame to the image buffer and then performing quick  
>> blits
>> to the xlib surface).
>
> Got to say Argh...
>
> 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.

I think that's only part of it.  For Mozilla, our core requirement is  
a way to quickly load bitmap data into surfaces other than the image  
surface -- for example, both the win32 surface and the quartz surface  
(in some cases) internally have a raw memory pointer that can just be  
written to; doing so is much faster than having to create a new image  
surface and then using cairo to draw one surface to the other.   
(Passing in original jpeg/png data to PDF would be a nice bonus, but  
only if the application gets to manage this data -- that is, we don't  
ever want to hand cairo the jpeg/png bits outside of a narrowly-scoped  
"give me data to embed right away" section -- but isn't required for  
us).

So there are two ways of doing this.  One is using the acquire/release  
approach I described, which would work for win32/quartz/directfb/etc,  
but wouldn't for Xlib due to the need to do SHM setup of the memory.   
Using cairo_image_surface_create_similar allows for the SHM setup, but  
has synchronization issues because it's not clear who owns the image  
surface or what its lifetime/usage is.

Given that the main objection is cairo_image_surface_create_similar,  
why don't we get rid of that API, and instead add a specific backend  
API -- cairo_xlib_create_surface_with_shm .  Then, the acquire/release  
API can be used in all cases, and all the synchronization problems can  
be hidden inside the xlib surface's release() implementation.  I think  
that the number of surfaces that can be written to directly will be  
much greater than those needing special setup of the memory involved,  
so this should simplify the API considerably; an app will just have to  
decide at surface creation time whether it wants to load data into it  
quickly, which I don't think should be a problem.

     - Vlad