Thread View: comp.windows.ms.programmer
3 messages
3 total messages
Started by Bert Tyler
Wed, 31 Oct 1990 00:44
Why are 256-color drivers slower than 16-color drivers?
Author: Bert Tyler
Date: Wed, 31 Oct 1990 00:44
Date: Wed, 31 Oct 1990 00:44
23 lines
1654 bytes
1654 bytes
> ... 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.
Re: Why are 256-color drivers slower than 16-color drivers?
Author: Marc Saes
Date: Wed, 31 Oct 1990 12:46
Date: Wed, 31 Oct 1990 12:46
36 lines
2440 bytes
2440 bytes
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
Re: Why are 256-color drivers slower than 16-color drivers?
Author: JT Anderson
Date: Thu, 01 Nov 1990 01:44
Date: Thu, 01 Nov 1990 01:44
42 lines
2837 bytes
2837 bytes
In article <590@nih-csl.nih.gov> 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? Sixteen color VGA, and to a somewhat lesser extent EGA, graphics modes provide at least two hardware assists that are lost in the 256 color modes. First, when scrolling data vertically, each byte you move can move all four bitplanes for 8 pixels worth of data. In 256 color modes, each byte you move is only 1 pixel. A significant difference. This advantage applies to any screen to screen bitblt where source and destination have the same byte alignment. Second, writing text is essentially a processes of blitting from a single bit per pixel source to a multi-bit per pixel destination. VGA write mode 3 provides a tremendious assist in this operation for 16 color modes. If only the foreground pixels of the text are being written, this can be very fast. If both foreground and background are being written, it is probably still significantly faster than the work needed to expand the bit per pixel source to a byte per pixel destination. If someone would make a VGA like card with an 8 plane 256 color mode, it would probably be nearly as fast for the most common operations as the four plane (16 color) modes.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads