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
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev