One thing to remember here is that doing a hilbert curve directly to
the Display is not a particularly representative test. It involves
fairly trivial work and lots of short lines done via the drawLoop
primitive that will ask for a display update at the end of each line. A
loop that blits a single pixel at a time to the Display in order to
fill it would be a similar quality of test - it might suggest 95% of
time going to the pixel transfer for example.

It certainly shows us that getting pixels from Display to Glass is slow
for many machines and that we could stand some improvement there. BUT it
isn't a very typical case and we shouldn't fall victim to
dumb-benchmarkitis, a common and occasionally fatal disease.

A long time ago Andreas posted a couple of interesting graphics
benchmarks that I've no longer got the code snippets for. Basically one
opened several browsers and the other opened each browser menu in turn
and chose each menu item up and down. The latter is a quite good test
of handling (faked) typical user actions - opening a menu and moving the
cursor up and down trying to decide what to do. Another good test would
be to open a workspace and fake-type a couple of paragraphs. Their
could potentially be different performance characteristics depending on
the speed of the fake-typing since there is (or at least was) code to
try to batch together several typed in characters at a time if the user
were typing fast.

More 'realistic' tests would provide a better evaluation of the real
impact of the speed of getting pixels from Display to Glass. Then we
get a better idea of how much effort is worth putting in to which
parts. Let's not get lost in details until we know if they're important
details.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
It is ten o'clock; do you know where your processes are?