🚀 go-pugleaf

bert@helix.nih.gov (Bert Tyler) writes:

> > ... 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 suspect it has something to do with operations on multiple pixels. For
example, in 16 color modes up to 8 pixels can be set with one MOV. This means
that filling operations are slower in 256 color modes. Also the 256 color
modes use more memory than fits in the A000-BFFF segments, which means that
bank switching has to be used to address all screen pixels. This is 
particularly troublesome for line drawing or figure drawing operations.
Therefore the 16 to 256 color ratio is also almost the speed ratio between
the 16 and 256 color modes (try atmoids).

I have written optimized routines for drawing triangles on EGA/VGA and I
suspect the 256 color version to be about six times slower than the 16 color
version.

Marc Saes             marc@stack.urc.tue.nl