Re: animate incredibly slow compared to 21.3

[Jan D.]

> It's possible that some X implementations use an internal bitmap, and
> then periodically transfer the contents to the physical display; such
> implementations may indeed arrange for some sort of coordination with
> Xflush, but it's not the traditional function (I believe typically
> such backend buffered display updates are mostly based on time
> anyway).

Not the X server itself, but some toolikts, like GTK does this kind of 
double buffering.  The bitmap contents is transferred to the window 
when there are no events to process in the GTK main loop.  I don't 
think double buffered schemes are time based, most just do a lot of 
drawing to the bitmap and when done, transfer it to the window with 
some X call (XCopyArea mostly).

Myabe this is what Emacs should do, create a pixmap, do its drawing 
there, and then XCopyArea it to the window when done.  Emacs already 
does this for images.  It is not hard to implement, just replace the X 
window in all X calls with the pixmap.  The downside is that it uses up 
more memory in the server.

        Jan D.