Re: Re: how to write snappy benchmark?

On Sun, Jul 06, 2003 at 08:19:26PM -0400, Havoc Pennington wrote:
| Not sure backing store papers over the real problem. Two real problems
| it's the correct solution for are:
| 
|  - expose event -> application -> repaint round trip causes latency;
|    saving window contents on the server side is the right solution 
|    here, it avoids the round trip entirely

(As we've all said before) it would be great to quantify this.

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.

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.

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

If you've taken a look at what game engines do routinely -- 3D transform
bounding boxes, select versions of geometry depending on the
angle-of-view they subtend, cull fully- and partially-visible geometry
from enormous databases, compute shadow volumes, sort geometry so that
transparency is handled correctly, sort objects so that attribute
changes are minimized, etc. -- then you know that they do a lot of
expensive work, too, yet maintain good interactivity.  Why is caching at
a higher level necessarily less effective for text than it is for other
objects in apps like game engines -- especially when you begin to
consider non-static text as well as static text?

As an historical example, Tom Davis's "zip" text editor that used IrisGL
for rendering did things like caching textures for common digraphs.
Since overhead is so high for drawing single glyphs, this yielded almost
a two-to-one performance improvement for drawing.  

There are plenty of similar optimizations used in scene-graph
implementations that might carry over to the 2D world.

| "Stale images" are only an issue if your image is changing, and for
| the most part here we don't have any kind of animation, we're just
| talking about repainting something static.

Maybe I missed a turn in the conversation, and apologies for the
irrelevant intrusion if so.  But I thought we were talking about UI
responsiveness in general, so things like window moves, window resize,
popping-up menus, etc. are all on the table -- not just exposures.

| An interesting question is: if you never had to wake up applications
| just to handle exposes, would that mean you could more effectively
| keep unused applications paged out and get better system performance
| as a result? No way to tell without hard data really.

If there are some ex-NeWS folks around, they might know.

Allen