[cairo] XDBE

[Bill Spitzak]

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 
back-buffer-swap command).