Re: Re: how to write snappy benchmark?

On Sun, Jul 06, 2003 at 07:27:46PM -0700, Allen Akin wrote:  
> 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?

It certainly isn't *necessarily* less effective, but it may turn out
to be in practice. You'd have to profile each specific thing to be
rendered, presumably.
  
> 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.

When drawing something that's never been drawn it seems pretty clear
that backing store isn't a performance win, though it does avoid
flicker.

Window move/resize does cause exposures on a bunch of apps underneath
the window being modified, though, and handling those exposures will
be using CPU time and causing context switches and so forth. By
avoiding exposures on the passive apps underneath the window you're
move/resizing, you might ideally hope to have only the app being
resized and the X server using your CPU.

Practice falls short of the ideal, since the window manager, the
workspace switcher, the window list, and probably other things are
still going to wake up on each resize event. Most of them don't do
much expensive though.



One thing I think would help a lot with performance issues would be to
get rid of all flicker/tearing, e.g. by having a double buffer that
spans client app and window frame, and syncing client resize with
frame resize, as in the thread Soeren linked to.

If you get rid of all the drawing mistakes, you're left seeing the
real, genuine speed with no effects that produce illusions of fast or
slow, and no weird stuff such as the server scheduler starving all
clients except the WM.

Accurate visibility of performance problems has to be a positive first
step toward fixing them.

Havoc