spitzak at d2.com
Tue Nov 22 13:03:46 PST 2005
Adam Jackson wrote:
> Right now very few apps use it, so I guess it works as well as it ever did.
> The demo app seems to work though. The API's a bit overblown, but, welcome
> to X.
> Internally it's a fairly decent implementation, it just kicks the buffer swap
> through the current GC's CopyArea call so it should natively take advantage
> of any underlying acceleration.
Having used it quite a bit, I am having no trouble. The only real bug is
that if you resize a window, it sometimes swaps in the black/garbage
from the backing buffer. It should do nothing until the program sends a
swap-buffer command to indicate it has updated the back buffer. I have
found this happens if you try to double-buffer the top-level window that
the window manager sees. But if I make a child window that fills the
top-level one, use double buffer on that, and resize, draw, and swap
that myself without doing XFlush, it works great and you get smooth resizes.
Another possible better fix is that resizes should copy *into* the
backing buffer the current contents of the screen. Then if it
accidentally gets swapped back before the program finishes drawing it,
the user will not see any change in the undrawn areas.
> It could do with some loving though, between
> that, Composite, and the mi backing store layer we end up with as many as
> three backing copies of the front buffer, which isn't what I'd call optimal.
I agree. It would be nice if *all* backing copies went to the same area,
no matter how they are created. Ignore any minor glitches (ie I think
the composite extension could show partially-updated backbuffer, just
try to avoid recompositing except when a program sends the
More information about the cairo