Re: Snappy GUI response

On 4 Jul 2003, Owen Taylor wrote:

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

   It's not the actually drawing that is a problem.  It's having
to get an expose event at all.  If a button rarely changes, set
the image as a window background and request no expose events
on it.

   I advocate backing pixmaps for as many windows as it 
makes sense, and no expose events on them.  Not only is this
extremely fast even if server is rendering in software, but
it looks great (you don't see redrawing).  That is, save all
your expensive rendering, don't keep redrawing it.  Put it in
a pixmap and set it as the window background.  There's also
a good change this pixmap will end up in video ram rather than 
system ram.

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

   I don't know which apps use which toolkits, but Netscape 7
is obviously not setting window backgrounds.  Exposed areas have
junk in them until a second or so later when it gets around to
repainting them.


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

   The window manager is an app.  The modern window manager's
performance sucks as bad as the rest of the apps.  I looked at RH 8
or 9 (don't remember which) and the root window was obviously being
painted via expose events rather than letting the server handle
it automatically.  It looked really bad and contributed alot to
the sensation of watching things repaint.

   I think the biggest visual problem is watching things repaint.
This is not because the server is slow because I can verify that
we're not falling back to software.  It's the get expose, redraw,
get expose, redraw... that's killing it.

   Maybe whatever the apps are doing are thwarting toolkit optimization
and it's not the toolkit's fault, but whoever is doing it, it's why 
everything looks so slow.


			Mark.