Re: Re: how to write snappy benchmark?

On Sun, Jul 06, 2003 at 03:14:13PM -0700, Mark Vojkovich wrote:
| > * Assuming the apps are capable of redrawing quickly enough to maintain
| > interactivity, and the scheduler gives them time to do so. 
| 
|    I think if that were true we wouldn't be having this discussion.

Possibly.  It's important to know exactly why things are misbehaving
now, and I haven't heard consensus on that yet.

It's not due to lack of horsepower in the graphics subsystem, for
several reasons including:  (1) Most 3D scenes in games are vastly more
expensive to render than the typical GUI, yet are rendered with
excellent responsiveness.  (2) Windows often seems faster when running
on the same hardware.

There may be scheduler issues.  Alan said:

	The 2.4-ac tree has the O(1) scheduler as has stuff like Red
	Hat.

My Ti4200 machine running RH 2.4.20-18.9 isn't noticeably snappier than
before, so I don't know what's up there, yet.

And of course if some critical drawing operation isn't accelerated,
there goes the ballgame.  RENDER does add some risk in that respect.

But I suspect it's mostly due to the toolkits and window managers being
based on abstractions that optimize for goals other than performance.
Those of you who have used Open Inventor and Performer, two high-level
toolkits that yield significantly different performance for similar
scenes running on the same hardware, know what I have in mind.  But
without more hard data that's just a guess based on experience.

I brought up the subject of double-buffered displays without per-window
backing store because the backing store just papers over the real
problem, and costs a fair amount of memory in the bargain.  As you said,
if the apps take a long time to render, you're still stuck looking at a
stale image for a noticeable amount of time.

|    Most OpenGL apps are the types of apps that don't need to handle
| expose events.  And it's a good thing too, because they'd probably
| suck at it.

In the IrisGL days, many apps were based on a simple model a lot like
games:  Render continuously, and structure your pipeline so that there's
no more than one frame of latency between an input and the first drawing
command issued in response to it.  Exposure events were irrelevant.
Rendering was always double-buffered and there was no expensive backing
store per-window.  Those apps updated the screen cleanly, were extremely
snappy, and were a joy to use.

Most current OpenGL apps wait for exposure events so that they're not
burning CPU cycles unnecessarily.  But if they're otherwise structured
in a similar way, and they're dispatched quickly enough, there's no
fundamental difference between them and the old IrisGL apps.  If such an
app can render a scene in a frame time, it feels fast.  There's nothing
special about the API used for drawing, so I don't see why OpenGL apps
would be any worse than Xlib-based apps or apps using any other
reasonable accelerated API.

Allen