Re: Snappy GUI response

On Thu, 2003-07-03 at 18:56, Mark Vojkovich wrote:
> On 3 Jul 2003, Owen Taylor wrote:
> 
> > On Thu, 2003-07-03 at 15:52, Mark Vojkovich wrote:
> > >    This is because people writing X applications (and particularly 
> > > X toolkits) have little understanding of graphics performance issues
> > > in the X-Window system.  They say they do, but the results (slower
> > > and slower toolkits every year) imply that they don't.  Most of
> > > these problems lie in the continued failure of toolkits to reduce
> > > the round trip communication between the client and the server.
> > 
> > * Without any firm definition of *what* we are talking about,
> >   I think placing blame is a bit silly.
> 
>   He did leave it a little open ended, but you can guess what
> he's refering to - interactivity, and I know what the problems are.
> I've watched what these apps are doing and they're not getting
> better.
> 
>   The biggest problems I see with X apps in general:
> 
> 1) Failure to compress events.  Eg. handling of exposures, resizes,
>    etc... without checking if there are other events of the same
>    type in the queue.

OK, so you aren't looking at GTK+ applications. GTK+ pretty exhaustively
compresses both of these. (Some complicated GTK+ apps do enough
themselves to break the compression... Mozilla isn't really a
GTK+ app in a meaningful way.)

> 2) Failure to make use of window backgrounds.  X will do alot of
>    work automatically for you if you let it.  If the contents of a
>    window don't need to change, set them as the window background.
>    At least set it to your clear color/pixmap so that you don't have to
>    waste bandwidth for that.

This tends to involve a lot of encapsulation breakage to do... 
once you have toolkit, theme, and application involved, *knowing*
that an area doesn't need to be repainted can be quite difficult.

And how many billions of pixels a second of constant fill can a
modern nvidia card? Optimizing out XFillRectangle() doesn't strike
me as being that important.

(Note that setting the backgrounds to avoid flashing is much
simpler, and is something that most GTK+ apps do pretty well.)

> 3) Poor performance analysis on the apps themselves.  I see a whole lot
>    of overdraw within apps.  Not only are they doing more exposes than
>    they really need, but these exposes are very heavy handed.  I
>    see so many app's widgets that don't get drawn once during an
>    exposure, but several times.  I'm not kidding.  I spend alot of
>    time under a dubugger trying to repro direct rendering bugs in my 
>    work.  Just unmap an occluding window and watch an app respond to the
>    single expose rectangle.  I sit there watching it draw and clear
>    and draw and clear some widgets many times in response to a single
>    expose event.  This type of behavior is widespread and much worse
>    than it was back when people were using Motif.

>    With FVWM I can move windows around and I never see the server 
> repainting anything.  It's all seemless.  With more modern window
> managers I get to watch things get repainted.  This isn't because
> X is slow.  I can verify that it's not falling back to software for
> anything.  This is slow because window managers are getting expose 
> events for everything and handling them badly.  Maybe better scheduling
> at the kernel level will help a little, but that's not the root of
> the problem.

I'm really quite confused here about how the window manager can
affect application repaint performance...

What you may well be seeing is bad X server scheduling between the
window manager and application contents... once repainting window
manager frames takes a significant amount of time, opaque resize
becomes a fairly hard scheduling problem.

(There are some outstanding patches for GTK+/metacity that largely
fix this by letting the window manager know when the app is done
painting a frame.)

Regards,
						Owen