Re: synchronizing window frame/client repaint
- From: Owen Taylor <otaylor redhat com>
- To: dominik vogt gmx de
- Cc: wm-spec-list gnome org
- Subject: Re: synchronizing window frame/client repaint
- Date: Thu, 19 Dec 2002 11:03:50 -0500 (EST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]