gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cairo x11 surfaces


From: Eric Wasylishen
Subject: Re: cairo x11 surfaces
Date: Thu, 13 Oct 2011 15:28:26 -0600

Forgot to add, thanks to Matt Rice for sending me some example code of this 
technique.

On 2011-10-13, at 3:26 PM, Eric Wasylishen wrote:

> Hi Fred,
> 
> I had a look at implementing it today, and it turned out to be easier than 
> expected so I finished & committed it.
> 
> If we run in to problems we can switch back to XGCairoXImageSurface before 
> the next release, but it looks promising. In particular, I tried X forwarding 
> to Apple's X11.app, which only supports 24-bit windows, and the new surface 
> is significantly faster than XGCairoXImageSurface, and the alpha channel of 
> images is correctly preserved (unlike XGCairoSurface).
> 
> Riccardo, this should fix GNUstep on the 16-bit display configuration where 
> it wasn't working for you. If you could test it some time and let me know if 
> it works, that would be great.
> 
> Cheers,
> Eric
> 
> 
> On 2011-10-13, at 1:08 AM, Fred Kiefer wrote:
> 
>> This sounds very promising. Maybe we can get rid of XWindowBuffer that way. 
>> Do you think this change should go in before the release or after?
>> 
>> Fred
>> 
>> On 12.10.2011 18:54, Eric Wasylishen wrote:
>>> 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/
>> 
>> 
>> _______________________________________________
>> Gnustep-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]