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.