Re: synchronizing window frame/client repaint

[Dominik Vogt <dominik vogt gmx de>]

On Thu, Dec 19, 2002 at 10:33:25AM -0500, Havoc Pennington wrote:
> 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.

This just synchronizes the redraws and saves some of the
(relatively fast) frame redraws.  Applications still redraw too
much.  Don't get me wrong - if it helps it is a valid approach,
but I still think one could gain more by limiting redraws to the
bare minimum.

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

Yes, I know that thread.  What Owen describes helps a bit, but can
not fix two problems:

 1) It utterly fails when the window grows horizontally but
    shrinks vertically or vice versa.

 2) It can not take care of subwindow hierarchies.  For example,
    it fails in the scrollbar example I gave earlier:

    Client window with NW gravity, with a scrollbar subwindow with
    NE gravity.  The frame is shrunk on the left side.  Either we
    have

    a) Frame is shrunk first:
       1. Client window is shifted right, scrollbar is moved out
          of the visible area.
       2. Client window is shrunk, scrollbar jumps back into
          visible area and is redrawn.
       ==> scrollbar flickers

    or

    b) Client is shrunk first:
       1. Client window shrinks, scrollbar jumps to the left.
       2. Frame is resized, client shifts right, scrollbar moves
          back to original position on the screen.
       ==> scrollbar flickers
    
> 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.

Are you using GTK to draw window frames?  The code has been in
fvwm for a long time without any problems.  But regardless of how
hard you try, opaque resizing still flickers way too much.

> For most apps bit gravity doesn't help, because they "stretch" the
> whole window contents as you grow the window.

"Most apps"?  The only ones I can think of where this makes sense
are image manipulation programs and windows to edit or display
text.  What would be the use of buttons growing or shrinking with
the window size?  Sure, I have seen applications doing that, but
that is annoying.  My guess is that the vast majority of window
contents could be kept and just moved around.  Of course the
limitation to 9 gravities is unfortunate.  More granularity would
be good.

> Bit gravity never helps
> with GTK for example, and I would expect the same with Qt.

Yay!  That's why I'm not using wither ;-)

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

I think the sheer amount of time for the various redraws is worse
than the lag, but that depends on the application.  Anyway, there
are a lot more reasons for double buffering in X.  For example, I
could imagine a lot of nifty graphical effects when mapping a
window if it were possible to draw it into some buffer before
mapping it.  Just think of windows that fade in and out when
opened or closed.

Bye

Dominik ^_^  ^_^