Re: synchronizing window frame/client repaint

[Havoc Pennington <hp redhat com>]

On Thu, Dec 19, 2002 at 10:37:10AM +0100, Dominik Vogt wrote:
> On Wed, Dec 18, 2002 at 03:04:56PM -0500, Havoc Pennington wrote:
> >  a) lag between the window frame and the application window. 
> >     especially with the current XFree86 scheduler, the app tends
> >     to get starved so the frame is redrawn a lot more often.
> 
> I seriously doubt this explanation.  All you can do in the window
> manager is to resize the frame less often, which makes the
> operation rather choppy.  A well written application *has* to
> ignore many of the ConfigureNotify events in order to not redraw
> excessively.

Try running XFree with the -dumbSched option.  GTK for example ignores
tons of ConfigureNotify. However, the smart scheduler in XFree
increases the priority on clients receiving input events. So the WM
always runs, and the app does not get its X requests processed.

The scheduler isn't the whole issue, there's also just inherent
out-of-syncness due to random factors and the fact that frame and
application almost 100% likely redraw at different speeds, no matter
how fast they can draw.

If you try my counter approach, you can see how things work when you
sync up. It's very different. It *is* a bit "choppy" due to lag type
b), things just not being fast enough, but you can tell that lag a) is
gone.

> In my eyes, the root cause of the problem is that the application
> does not know on which border it is resized and in which direction
> before the frame is actually resized.  Thus, it can not set proper
> bit_gravity and win_gravity on its windows to minimize redraws.
> With the correct bit_gravity, the X server would move the window
> contents to the right place automatically and no Expose event
> would be generated for this region.

See also:
http://mail.gnome.org/archives/wm-spec-list/1999-November/msg00088.html

Metacity actually has code to do what Owen suggests but it's disabled
because there used to be a GTK bug rendering it unusable. However we
think that might be fixed now.

For most apps bit gravity doesn't help, because they "stretch" the
whole window contents as you grow the window. Bit gravity never helps
with GTK for example, and I would expect the same with Qt.

> Another problem is that it is not possible to resize a tree of
> windows in a single request.

Well yes, this is one of the reasons why you'd need double-buffering
to fully fix a). However, for example GTK has relatively few child
windows, and if you sync things up with the counter the lag for child
windows is not that noticeable.

Havoc