7

Wikipedia article for WinG says the following:

WinG would also perform a graphics hardware/driver profiling test on the first execution of the program in order to determine the best way to draw DIBs. This test showed a window full of red curved lines, sections of which would wobble as performance was tested. Once WinG had determined the fastest calls that did not cause graphics corruption, a profile would be saved so that the test would not need to be performed again.

What are the different "ways to draw DIBs" this performance test was trying out, and why some of them would sometimes work and sometimes not?

1
  • 1
    Device drivers written by hardware vendors intent on getting their latest fast board out the door ASAP? Oct 12 '20 at 23:02
9

Different computers had different kinds of caching between the CPU and the motherboard RAM, and some video cards had ways of taking data from memory without involving the CPU. If any data copied from memory would involve the CPU, flushing the CPU cache to motherboard RAM before the copy operation would uselessly degrade performance, but if a display card uses bus mastering or other such techniques to grab data from motherboard RAM, failing to flush the cache before drawing may result in the display card receiving "stale" data.

Such issues were made worse by the fact that many display cards could accept data faster during vertical and horizontal blanking intervals than they could during the active display period, and thus provided features that could perform graphics operations "in the background". Depending upon the display card, a request to display some data that was stored in main memory might report that it had been completed as soon as all of the operations were scheduled, rather than when they were completed. If data in main memory were changed between the time the drawing commands were issued and the time they were actually carried out, the card might receive an updated version of the data, rather than receiving the data that had been stored in RAM at the time the commands were issued.

Ideally, display drivers would take care of such issues automatically, but in the mid 1990s, motherboard and display card designs were both in flux, and there wasn't always a consensus as to who was responsible for handling caching issues under what circumstances. While it would be possible to always force caches to be flushed whenever drawing anything, and then wait for each drawing operation to fully complete before returning control to the calling program, doing such things would severely degrade graphics performance. Instead, the WingG tester tried to identify what combination of cache flushing, completion waiting, or other such techniques would run most efficiently while ensuring correct operation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.