cairo x11 surfaces

[Eric Wasylishen]

Hi, I just wanted to report on a bit of research I did on this. There was a 
suggestion on the cairo mailing list [1] to implement double buffering on X by 
doing the following:

- create a cairo xlib surface for the window (could be 32-bpp with alpha, 
16-bpp no alpha, etc.)
- call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far 
as I know the resulting surface is guaranteed to have an alpha channel. I 
skimmed over the implementation and it looks like it tries to create an xlib 
surface with alpha; if that fails, it creates a 32-bpp image surface and 
returns that.
- when expose events are received, use cairo drawing methods to copy the 
desired region from the back buffer to the window. This should boil down to a 
efficient X call if both surfaces are stored on the server, or otherwise cairo 
should handle using shared memory to transfer the 32bpp image surface to the X 
server, and converting it to the needed format.

Now, I haven't tested this, but it looks like it should work and looks like 
exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard 
work. :-)


It's amazingly hard to find tutorials on how to set up double buffering. Here's 
another comment I found: "A conversation with keithp indicates that his current 
thinking is that the right way to do double buffering is via an explicit copy 
from a separate pixmap. This is portable to absolutely everywhere, and requires 
no magic. Probably there will soon be a convention for the compositing manager 
to handle the double buffering on systems where one is running, since it needs 
to buffer anyhow. But this would be in the future." [3]

--Eric

[1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html
[2] 
http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar
[3] http://xcb.freedesktop.org/XcbNotes/


On 2011-09-19, at 4:37 AM, Fred Kiefer wrote:

> On 19.09.2011 08:49, Riccardo Mottola wrote:
>>> Sorry, I was premature to commit that; I was hoping to work on it
>>> yesterday but didn't have time, so 'll revert it for now.
>>> 
>>> I did some testing with Riccardo and we found that using
>>> XGCairoSurface (so using cairo xlib surfaces) did indeed fix the
>>> problem he was observing.
>>> 
>>> By switching to XGCairoSurface we get:
>>> - much better drawing performance for X over ssh (tested)
>>> - potentially better drawing performance overall (not tested, but
>>> reported on the cairo mailing list)
>>> - better font rendering (subpixel antialiasing support)
>>> - support for running on X servers only supporting 16-bit visuals,
>>> whereas XGCairoXImageSurface fails completely
>>> - delegate more work to cairo and rely less on XWindowBuffer (e.g.
>>> cairo handles shared memory)
>> Indeed. Essentially one of the objections that was made to
>> XGCairoSurface was transparent windows on non-32bit displays.
>> 
>> My main development workstation is 32bit capable but is set as default
>> to 24bit. The same is true for my laptop.
>> 
>> I am able to get the opacity test in GSTest for both surface types on
>> 24bit. (I can't get the same compositing effect to work with the alpha
>> channel of NSColor in neither cases).
>> 
>> So essentially, I found no problems on 24bit and on 16bit the situation
>> improved a lot. Most probably without image caching it would have worked.
>> 
>> Eric still hoped to find a buffer which would abstract the depth level,
>> but apparently art doesn't use that either.
>> 
>> Did you have any problems with XGCairoSurface, Fred?
> 
> No, and I never said so. I just wanted to know the reason why Eric made a 
> commit he had argued against. I am working with 32 bit visuals and things are 
> OK either way on my machine.
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev