Re: synchronizing window frame/client repaint

[Havoc Pennington <hp redhat com>]

On Thu, Dec 19, 2002 at 01:20:30PM +0100, Matthias Clasen wrote:
> Would an extension to abort queued requests (mentioned in WhyX.pdf,
> 8.2) help ?  The client could the abort all queued requests before
> restarting the drawing when a new configure notify arrives.
> 

I would expect two problems with this:

 - same as the sync extension's "block all requests", modern 
   toolkits and WMs are just too complicated to block or 
   cancel all requests; you'll accidentally block or cancel 
   things that have nothing to do with drawing...
   I think we would really need something like:

     id = create_cancel_id ();
     push_cancel_id (id);
     send_draw_requests ();
     pop_cancel_id ();

     then later:

     cancel_requests_by_id (id);

   And the sync extension could use something similar for requests to
   block. Probably pretty annoying to implement in the X server but I
   just don't see using either the block requests or a cancel requests
   feature without this, unless I was writing a very simple dedicated
   client.

 - I think this is basically a "make things go faster" optimization -
   which will help with lag, by decreasing how far behind the client
   gets. But it doesn't really fix the problem in any fundamental way,
   we are still susceptible to scheduler problems (from both X server
   and the kernel), and no matter how fast both client and frame can
   repaint, it seems like a ratio thing to me - if frame repaints 2x
   as fast, then the client will get behind...

Havoc