Re: synchronizing window frame/client repaint

[Owen Taylor <otaylor redhat com>]

Dominik Vogt <dominik vogt gmx de> writes:

> On Wed, Dec 18, 2002 at 03:04:56PM -0500, Havoc Pennington wrote:
> > 
> > Hi,
> > 
> > Some of us have been discussing/experimenting with ways to make opaque
> > resize look better. Soeren Sandmann has a really nice analysis of the
> > problem (Soeren maybe you could post that here?). 
> > 
> > Basically opaque resize looks a little funny, Soeren tracks it to two
> > kinds of lag:
> > 
> >  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.

Resize compression is not enough (is any serious toolkit lacking
this?)

 - You'd agree that double buffering improves appearance
   while reducing total frame rate, right? I think this is
   another such case.

 - 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.

> 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 

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

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.

> 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.

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.

Regards,
                                        Owen