Re: synchronizing window frame/client repaint

[Soeren Sandmann <sandmann daimi au dk>]

Dominik Vogt <dominik vogt gmx de> writes:

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

Well, if they both are significantly smaller than the time between two
mouse events, then we won't get lagging, but in practice they aren't.

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

It is significantly reduced, but not gone. The (a) lagging is still
proportional to P_a.

> This just synchronizes the redraws and saves some of the
> (relatively fast) frame redraws.  Applications still redraw too
> much.  

I think you do have a point. If P_a < M - P_f, ie., if both
application and window manager are very fast, then we won't get any
lagging. I have seen this with FWVM 2.4 and the tk toolkit on much
worse hardware than I have now. There was almost no lagging with that
configuration.

However, as my calculations show, the lagging grows quickly as the
frame redraw time tends to M. If you have gradients or other expensive
drawings in the frames, it is not necessarily easy to just make it
really fast.

About applications redrawing too much, yes, reducing redraws will
help, but as long as lagging is proportional to a fraction with 
M - P_f in the denominator, we _will_ get lagging as the wm frames 
get complicated, no matter how fast we make the application.

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

I certainly think gtk+ should make better use of bit gravity.

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

Maybe I am misunderstanding you, but gtk+ does make use of bit
gravity. The TreeView in 2.2 resizes significantly faster than that in
2.0 because of bit gravity. If you unset the redraw_on_resize flag,
only the "uncovered" corner of a resized widget is scheduled for
redraw. The rest of the widget is left alone. The reason we can do
that is bit gravity.

It is often the case that a widget does not move within its window
(whether or not it "owns" that window). Making more aggressive use of
this fact will reduce both gtk+'s CPU consumption (fewer widget to
call "expose" on) and the amount of input gtk+ feeds to the X server.


Søren