Re: synchronizing window frame/client repaint

[Dominik Vogt <dominik vogt gmx de>]

On Thu, Dec 19, 2002 at 11:03:50AM -0500, Owen Taylor wrote:
> Dominik Vogt <dominik vogt gmx de> writes:
>  - If you read through Soeren's calculations, he does a
>    good job at explaining why coordination is needed to
>    avoid serious mischeduling. It's really hard for the
>    server to reverse-engineer what's going on and divide
>    time slices properly between window manager and client.

Perhaps we are looking at the problem from different points of
view.  In general the fvwm world is relatively free of GTK and Qt
apps.  Thus, we may usually see applications that differ in a lot
of aspects.  At least with the applications that I use personally,
the big problem is not scheduling but excessive redraws and wrong
gravities (xv, rxvt, netscape, mozilla, xterm, some fvwm modules,
lyx, acroread, ddd, many others).

> > 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.
> 
>  - All the "modern toolkits" I'm aware of - Qt, GTK+, Swing,
>    even to some extent Motif/Xt define layout in terms of 
>    procedures to calculate layout given a size. Determining
>    what 

Determining what?  Anyway, using a "modern toolkit" is not a good
excuse for setting the proper gravities ;-)  In my eyes that
rather points out the shortcoming of the toolkits.  (You can tell
that I'm not a big fan of toolkits, do you? ;-) )

>  - There are frequently elements where no single gravity
>    works. Think of flowed text, or more simply, a bevel
>    drawn around the entire window.

Sure, there isn't the one approach that suppresses *all* redraws.
But still it's better to only redraw the window with the flowed
text instead of all window controls.

> 
> I'll point out again:
> 
>  http://mail.gnome.org/archives/wm-spec-list/1999-November/msg00088.html
> 
> Which describes how with some window manager cooperation, 
> StaticGravity can be used to eliminate resize-from-the-left
> jitter of right or center aligned elements. But that's
> about all you can do.

Yes, I remember that thread very well.  App. and WM programmers
can do a few things, but flicker free resizing in general is not
possible with the current X interfaces.  The StaticGravity
approach only works on the left side of the window, not on the
right side.  The application would have to be informed of the
resize direction and given the chance to change the gravity before
the window is actually resized. :-/

> 
> > Another problem is that it is not possible to resize a tree of
> > windows in a single request.
> > 
> > Example:  You have a terminal window with a scrollbar which is a
> > sub window of the client window on the right side with
> > EastGravity.  The frame is resized on the right side.  Either the
> > scroll bar lags visibly behind the frame (growing), or the
> > scrollbar is outside the visible area of the window (shrinking).
> 
> You can, to some extent, suppress these effects by unsetting
> window backgrounds while resizing ... by a combination of this
> and simply getting rid of subwindows, GTK+-2.0 is quite low
> flicker within the client area. Not 100% but pretty darn low.

Of course you can't reinstate the old background once you have
deleted it, at least not if it's a pixmap.  And if you could, to
do so may well cause a race condition between the application
and the window manager, ending up with a random background.
(Think of windows with transparency effects).

> But if the window manager is getting all the X server time
> and the client can't redraw, things still don't look very good.

Well, then it's partially the fault of the window manager, isn't
it?  With a clever implementation, the window manager does not
need to redraw anything, at least for "normal" themes with
rectangular non-shaped borders:  draw all decorations into
pixmaps and set them as the backgrounds of the decoration windows.
The X server will redraw them automatically without any requests
from the window manager.  The redraw requests can easily be
limited to the parts that actually changed, even checking if it's
worth the effort at a given moment because the user has already
resized the window even further.

It is a bit difficult to implement this for opaque resizing, but
it works very well indeed for shading and unshading windows, which
nowadays is completely flicker free in fvwm.

Bye

Dominik ^_^  ^_^