Path: utzoo!utgpu!watserv1!watmath!att!att!emory!samsung!uunet!nih-csl!helix.nih.gov
From: bert@helix.nih.gov (Bert Tyler)
Newsgroups: comp.windows.ms.programmer
Subject: Why are 256-color drivers slower than 16-color drivers?
Message-ID: <590@nih-csl.nih.gov>
Date: 31 Oct 90 00:44:07 GMT
Sender: news@nih-csl.nih.gov
Organization: National Institutes of Health, Bethesda
Lines: 23


 > ... Windows 256-color drivers are slower than 16-color drivers ...

I've seen this stated authoritatively enough, and often enough, from
people who's messages consistently show that they know what they are
talking about, that I believe it to be true.  Certainly, with my PS/2 and
its vanilla VGA adapter, I'm never gonna see the difference myself <sob>.

On the other hand, my experience with writing the video drivers for
Fractint-for-DOS would have indicated just the opposite.  Reading/writing
a pixel to a 256-color screen involves a simple MOV (preceded on occasion
by a bank-switch, but only on occasion), and updating a line segment involves
a single REP MOVSB (two, if you have to switch banks somewhere in the middle).
The same functions on a 16-color EGA/VGA driver take enough INs and OUTs
to fill a Russian novel.  In FFD, the initial Mandelbrot image takes 
significantly *less* time in 640x480x256 mode than in 640x480x16 mode
just because of this.

So, why is this situation reversed in the Windows environment?  Something
to do with Windows (as opposed to video driver) overhead?

I'm asking this question in comp.windows.ms.programmer because I suspect
the answer is going to be more appropriate to this conference.