SirNickity wrote:So, is that the secret, then? Less about RAM type, more about the fact that DOS applications were pixel-pushers, and Windows leaned more on hardware 2D primitives support?
Pretty much.
Windows has a Hardware Abstraction Layer (HAL), which means that any access to hardware goes through an additional layer (basically the API and driver).
This is what allows Windows to run on a wide variety of display adapters without any applications requiring specific support for each resolution, colour depth or whatever.
It also allows hardware/driver developers to implement the logic that underlies the API calls in hardware.
The RAM type is an extension of that: Once you're designing a video chip that can do advanced rendering operations anyway, you might as well push the limits of the chip and strap some really fast memory onto it. Which generally only has an effect with these accelerated operations, because the CPU/bus can't access the memory that fast anyway.
It's basically an early version of the modern 3D accelerator/GPU.
The Amiga was actually one of the earliest machines to do this:
It has a blitter chip, which can perform linedrawing, blit operations, area fill and such. And it has hardware sprites, which can be used as hardware mouse cursor.
In the early 90s, the more high-end SVGA cards also started offering such features, and in Windows you could leverage this.
In DOS, each application would require specific support for each SVGA chipset, since there's no abstraction layer provided by DOS or the BIOS. So you'd get a lowest common denominator approach.
This finally changed when 3D accelerators arrived. Supporting a 3D accelerator was worth the extra effort, because your game would look considerably better and performance would also improve.
Besides, the hardware vendors would gladly assist in adding support for their 3D accelerator to your game.
SirNickity wrote:I'm also curious... somewhere between Win95 and maybe around Windows 2000, we weren't quite as dependent on filled rectangles anymore. That seems to imply that, after bus bandwidth had increased a few times over, GUIs moved back to pushing pixels again..? At least until Win 7, when viewports were handled as textures.
Yes and no.
That is, up to and including XP, there was still a reasonable amount of hardware acceleration in place for the GUI components. You can get quite far by just drawing lines, rectangles etc. You'd also use bit blit to drag windows with content.
With Vista that changed. The new Aero desktop was using textures, and ran on DX9. However, the driver model was not entirely complete yet, which meant that there was no way to accelerate the classic GDI API that Windows uses to draw its components. So all components were drawn into the textures with the CPU.
However, because the textures and the z-buffer could now handle overlapping and clipping etc in an elegant way, there was a lot less redrawing required than for XP, so effectively, performance was still quite good without acceleration. The window composition was hardware-accelerated, and that was enough.
With Windows 7, the driver model was updated, and GPUs could now accelerate some GDI operations in hardware again (but still only the basics, such as blitting). Microsoft also redesigned the GDI internals to make much better use of multithreading, by not making most calls blocking.
Direct2D was introduced as a new fully accelerated 2D rendering API as a successor to GDI.
Windows 7 also changed the way Aero uses backbuffering, to reduce memory usage. Drawing is done directly into textures in the AGP aperture.
See more info here: https://www.tomshardware.com/reviews/2d-windo … gdi,2547-2.html