Re: Re: how to write snappy benchmark?

On Mon, Jul 07, 2003 at 12:32:03AM -0400, Havoc Pennington wrote:
> There are many quite easy-to-think-of possible explanations other than
> window system architecture:
> 
>  - the actual graphics drawn are quite different in complexity 
>    for Windows and OS X

I understand why you are saying this, but I don't think the drawing
complexity is as relevant as you do.

In using these systems, I've observed that the responsiveness
characteristics of these display systems do not change significantlly
as the display complexity changes. X has a particular "feel", which it
has whether you are using twm or enlightenment, whether you tested in
1992 or 2003, whether you tested on AcceleratedX, microImages, or
XFree. Same with Windows; same with MacOS 9; same with
Nexstep/MacosX. This is because of display system architectural
decisions which are hard to change and are seldom optimized enough to
affect the feel.

The really plain black and white UI of Nextstep ran on the same exact
486 and P5 hardware as Windows. Windows was faster at doing beautiful
16bit color than Nextstep was at grayscale. Why? The nextstep display
server has a particular "feel" that comes from the DPS drawing model,
the division of labor between app server and application, and the way
graphics are rendered. Much of it comes from the fact that DPS (like
the new DPDF) is very hard to map onto the hardware drawing
acceleration operations of current video cards. They can "hide" all
that behind the excuse of visual complexity, but if you pull out MacOS
X DP2, it looked as simple as MacOS 9 and still "felt" piggish like
MacOS X and Nextstep. 

I once asked an Adobe DPS developer about Nextstep's slow performance
and he proceeded to give me an earfull about how machines needed to
move to multi-processor because graphics chips didn't do the right
kinds of drawing operations. It was obvious to me that these $13
graphics chips could move pixels around faster than an CPU was going to
in the next decade, but it was hard for him to admit that he needed to
find a way to take advantage of them.

Here are my characterizations of the different display systems. Of
course these are generalizations, and my reasoning is only partially
correct. However, I've not seen these generalizations proven wrong
yet.

Nextstep/Macos is very solid, correct, and sluggish. Of course this is
for many reasons, but the major factors are the drawing model
correctness of DPS/DPDF, the heavy use of software 2d pixel rendering,
the heavy use of backing store, a separate rendering server, and
'server-less' window management.

Win32 is very fast, exposed-redraw, and a little serialized. Of course
this is for many reasons, but the major factors are the short and
lightweight path between drawing commands and the hardware, hardware
which directly implements required drawing primitives, lightweight and
fast event notification, and the 'server-less' window management.

MacOX9 is very quick, serialized, and a exposed-redraw. Of course this
is for many reasons, but the major factors are the cooperative
multi-tasking OS model, the non-interleaved application layers, the
close connection between toolbox and quickdraw operations and hardware
acceleration, the "stop the world" menu and window operations, and the
'server-less' window management.

X is very concurrent, erratic, and somewhat lagged. Of course this is
for many reasons, but the major factors are the division of
responsiblity between several processes, a separate window manager,
toolkit over-reliance on heavyweight server 'windows' for widgets, the
many IPC roundtrips required for some operations, the scheduling of
event processing in the serialized xserver, and recently the lack of a
rich drawing model forcing client apps to do rendering and push
bitmaps around.

BeOS is very concurrent, solid, and mostly fast. Of course this is for
many reasons, but the major factors are the multi-threaded
drawing-server and client libraries, the DPS like rich drawing model,
the reliance on software rendering, the window management in the
display server, and fast IPC.

>  - OS X tends to have smooth animations to keep users from 
>    getting confused, where Windows has XOR wireframes

I don't know which Windows version you are looking at that has XOR
wireframes. Last time I dragged selected files in XP it drew an
amazingly beautiful alpha box. Windows also has plenty of annoying
animations (that you can turn off), but none of that affects the speed
at which 2d drawing operations occur in other windows. 

The drawing of that selection box has had the same "lightweight fast
response" on Windows from 3.1 to XP, while on nextstep/MacOs it's been
solid yet sluggish from 2bit grayscale to modern alpha channeled 32bit
color.

>  - the kernels are very different

In my experience, X has the same basic feel across kernels, and what's
more surprising, across X implemetations.

>  - the way threads work and the threading model of the GUI toolkits 
>    might be different (certainly is for Windows vs. Qt/GTK)

GTK is an interesting case to look at, because it's cross
platform. It's a heck of alot faster running on Win32 than on
X11. Boot up GIMP on both systems side by side and then pull out my
list above of the "characteristics" of the system and see if you
disagree.

> Anyhow, Longhorn remains to be seen. Windows doesn't do the alpha
> channel yet. When they add it, I assume they are going to have to keep
> around the contents of all the windows. (Or at least keep a kind of
> cache of said contents.)

I'm sure you're right that they will double-buffer all or most
windows. However, they'll probably backing store most of them on the
card itself to keep the drawing happening on the video card. After
all, by the time longhorn ships, video cards will have 128-256MB of
memory. They will probably also double-buffer the screen
itself. Here's to powerful display hardware.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [email protected]