Re: Re: how to write snappy benchmark?

On Sun, 6 Jul 2003, Allen Akin wrote:

> 
> If all you want to do is minimize the time from exposure to completion
> of repaint for static content, it's true that in some cases backing
> store is the best you can do.  But there are also cases where (at least
> at the hardware level) drawing is faster than  pixel copy.  So I'm not
> sure whether the case you cite is a compelling argument for backing
> store, or an argument for eliminating the involvement of the server in
> the local client case, or an argument for having the server execute
> drawing programs supplied by the clients (ala NeWS).  The latter two
> might cover the repaint case as effectively as backing store, yet be
> better solutions in other situations, so it's hard for me to say
> unequivocally that backing store is the "correct" solution.

   There are some things to keep in mind.  People often think of
a window as just the top level child of the root, but every button
is a window.  I count 13 windows in the decorations fvwm puts on
every window.  Each one of these potentially gets an expose event.
When you move the mouse and the window manager gets that event and
moves the window, there can be dozens of windows owned by various
apps getting expose events.  All of a sudden, each one of these
clients wants a piece of the CPU so they can redraw.  Moving
the window back and forth can be generating hundreds of exposures
a second across several clients.  While bad scheduling can certainly
make this situation much worse, there's a limit to miracles that
good scheduling would be able to do.


> 
> With respect to reducing the server's involvement in the case of a local
> client:  Direct rendering reduces latency by minimizing the delay in
> start-of-rendering caused by queueing the drawing requests.  In my
> experience this is a very significant effect.  I don't remember if it's
> been mentioned so far in this discussion.

   I believe that direct rendering will make the latency worse in
the case of exposures.  It does for 3D.  Nothing has changed from
the description I gave above except that now the apps all have
to synchronize with the X-server before they can render.  Your
rendering is no longer pipelined with the window move.  You just
stuck a big bubble in between those two operations.


> 
> |  - recomputing what to render is expensive. For example, drawing
> |    Unicode text involves a fair bit of glyph selection, positioning,
> |    and so forth. The best way to cache that may well be in pixmap
> |    form, i.e. by just saving the pixels that were drawn, rather 
> |    than caching it at any higher level.
> 
> I understand some of this at a gut level, but I haven't looked at the
> code in enough detail, so it's hard to compare it with what I do know.

   I think most 3D apps don't get exposures.  Apps that draw in
a loop never have to deal with any of this stuff.  Most games 
definitely don't.  It's a different world.


			Mark.