I don't understand why by the way WinXP,7,etc.. are slower. Does it mean that modern cards actually accelerate 2D GUI stuff with more features in hardware to help than the older one with older os? I understand that actually gui does many animations that years ago did not exist (who missed them...) but are they so complex to need some newer gpu? Or newer os just use different 2D acceleration?

I know Windows Vista+ doesn't really use the same old GDI Windows XP and below did, it uses DWM, and GDI applications are not hardware accelerated anymore (Windows 7 reintroduced some acceleration). In Windows 7 + WDDM 1.1 drivers DWM only writes to the GPUs memory, so it is probably pretty bandwidth intensive (for the PCI bus).

In Windows XP does the difference hold with the Themes service disabled?

This is a question I've been wanting to answer for a while. I just haven't gotten around to it yet!

The biggest problem with modern GPUs is that they have dynamic clock speeds and voltages.
How fast they are in 2d is strictly a case of how fast the driver allows them to run. For a modern GPU, the desktop/2d tasks are seen as 'idle', and only when you start up something like a video decoder or create a 3D device with OpenGL or D3D, will it switch the GPU into a faster mode.
This makes benchmarks in 2d completely meaningless. They run at a speed that the vendor considers to be the best compromise between performance and power consumption.

Something else came to mind - not all AGP is created equally. Specifically VIA chipsets seem to have a deficit in GUI performance for some reason. It can be felt in-use, and also quantitatively measured.

Standard Def Steve wrote:

(I tested this with a Radeon 9250 PCI and 9800 Pro AGP on a 2.66GHz P4 system). Bump the resolution up to 1920x1200 and the difference between PCI and AGP is like night and day. For example, when you reload a web page, you can see the PCI card refresh the screen from top to bottom. With AGP, it all appears on-screen at the same time.

This could be related to GPU and/or video memory bandwidth.

386SX wrote:

I don't understand why by the way WinXP,7,etc.. are slower. Does it mean that modern cards actually accelerate 2D GUI stuff with more features in hardware to help than the older one with older os? I understand that actually gui does many animations that years ago did not exist (who missed them...) but are they so complex to need some newer gpu? Or newer os just use different 2D acceleration?

Yep, Win7/8/10 uses a very different method of 2D acceleration than XP. Many new apps designed with the new OS in mind can use Direct2D instead of GDI.

So, with a proper video card or IGP running on a proper bus, video throughput on 7/8/10 is greater than XP. Web browsers scroll smoother and with lower CPU usage than XP ever could. Web pages with lots of HTML5 animation look completely fluid on 7 while they are a tad choppy on XP. And EVR is so much better for video playback than the clunky overlay or VMR that XP used.

It just takes a video card that supports all of 7's WDDM features in hardware, and most if not all cards since GeForce 8 do.

swaaye wrote:

Standard Def Steve wrote:

(I tested this with a Radeon 9250 PCI and 9800 Pro AGP on a 2.66GHz P4 system). Bump the resolution up to 1920x1200 and the difference between PCI and AGP is like night and day. For example, when you reload a web page, you can see the PCI card refresh the screen from top to bottom. With AGP, it all appears on-screen at the same time.

This could be related to GPU and/or video memory bandwidth.

This one is a built-by-ATI model with 128-bit memory. It's faster at 3D than my 64-bit FX5200 AGP. However, the 5200 is right up there with the 9800 Pro in 2D speed. No signs of struggle at all. I'm 99% sure that the PCI bus is the primary bottleneck for the 9250 in 2D mode.

Interesting thing I've found with Mozilla Thunderbird is the Direct2D rendering is very slow on AMD cards in the 2000-4000 range. It's painfully slow to scroll messages. If you disable Direct2D in Thunderbird config, scrolling is fast. Firefox can also have font rendering problems if Direct2D is enabled with these cards.

I'm not entirely convinced that hardware acceleration is totally gone for GDI. It's not slow enough. It's certainly nothing like say running a generic VESA display driver on XP where there is truly no acceleration at all.

/\ In Windows Vista it was, but a few things were handled by DWM so it could still be faster when dragging windows and stuff like that (as windows did not have to be redrawn). Windows 7 reintroduced some hardware acceleration for GDI.

Standard Def Steve wrote:

Yep, Win7/8/10 uses a very different method of 2D acceleration than XP. Many new apps designed with the new OS in mind can use Direct2D instead of GDI.

That is one thing...
Another thing is that the GDI acceleration works differently as well.
A huge difference between XP and later GUIs (say 'Aero-based') is that the later ones are designed for GPUs, and basically run on D3D9.
This means that they assume your video card has 3d texturing capabilities and zbuffering.

You see, in early days, video memory was expensive, so you often didn't have more video memory than what was visible on the screen, at least in high resolutions and high-colour modes.
This meant that everything had to be drawn directly on screen, because double-buffering was not an option.
So to solve the z-order overlapping, the GUI framework kept track of bounding rectangles of each window (and in Windows, every component is a 'window', also buttons, checkboxes etc) and their z-order, in a tree-structure.

Using this tree, the framework could determine exactly which parts of which windows were visible, and which parts were not, and it would redraw only those parts of the windows, directly onto the screen.
You have probably seen this in action: when you drag a window quickly, you 'invalidate' the rectangles underneath, but they do not get redrawn instantly. You'll see remnants of your dragged window there, until the OS has enough time to redraw everything, and the underlying controls 'snap' back into place. Or of course, if the underlying application froze, it can no longer redraw, so its window remains corrupt.

By the time Vista came along, even the simplest integrated GPUs had basic Direct3D 9 acceleration capabilities, and videomemory was not an issue anymore either. You no longer wanted flickery-teary GUIs, you wanted smooth, solid GUIs with double-buffering and v-sync.
So, Microsoft dropped the old tree-of-rectangles, and instead let the GPU solve it. It's very elegant really:
Each window gets its own offscreen video buffer, basically a texture. The desktop is 'composited' by rendering each window as a textured quad, with the z-value of that window. The zbuffer will then automatically handle the z-order for you.

A huge difference in this approach is that overlapping windows no longer invalidate eachother, because they are not physically overlapping the offscreen buffers, and their contents do not get corrupted. This means that there is a lot less redrawing going on.
This is the main reason why Windows Vista got away with no GDI-acceleration so well: sure, it had to redraw components on the CPU, but it didn't have to do it all that often.
There was a catch though: because CPU-access to GPU-managed buffers is expensive (contention issues and all that), Vista had both a system memory and a video memory buffer for each window. The CPU could update the system memory buffer, and it was then staged to the GPU when done.

With Windows 7, Microsoft reintroduced GDI-acceleration. However, it worked in a completely different way from how it was implemented in XP and earlier.
It built on the Vista system, but removed the need for the system memory. Instead it used 'aperture memory' (you know the AGP aperture? It doesn't really have a name for PCI-e, but the idea is the same: memory that is shared by CPU and GPU). This means that the GPU can now draw directly to the backbuffers, opening the possibility of hardware-acceleration once more. It also means that you don't need a texture in video memory if you already have one in aperture memory, so Windows 7 is more efficient than Vista with its memory usage.

However, only a few things are actually GPU-accelerated. Mainly blits, alphablend, colorfill and font rendering (ClearType). XP had all sorts of operations such as line-drawing, rectangles, circles, polygons etc. These are not accelerated because GPUs use a very different way of rendering than what is required for these old bitplane-based operations (then again, modern CPUs can do these very quickly, so it may not even be worth it to set up specific commands for the GPU, which takes a lot of overhead). Which is why Direct2D was introduced: a new API which supports rendering operations that map nicely to GPU operations.

Another thing I seem to recall from GDI in Windows 7 is that they made GDI asynchronous. That is, drawing operations from different GDI contexts can overlap to speed up processing. I cannot find a reference to that at the moment though.

Anyway, TL;DR: There's a difference between 'GDI acceleration' and 'GDI acceleration'.

matze79 wrote:

AGP is 66Mhz, PCI 2.1 is 66Mhz, so there is no real Difference beetween Trio AGP and PCI.
The Trio 3D AGP is no AGP Chip. It does not even use a AGP Feature.

66mhz PCI was rarely implemented except as PCI-X. The Powermac G3 Blue and White and G4 Sawtooth use a 66mhz PCI slot for video, but I haven't seen much else that does. The PCI slots on PC motherboards are still 33mhz as far as I know.

Scali wrote:

That is one thing... Another thing is that the GDI acceleration works differently as well. A huge difference between XP and late […]
Show full quote

Standard Def Steve wrote:

Yep, Win7/8/10 uses a very different method of 2D acceleration than XP. Many new apps designed with the new OS in mind can use Direct2D instead of GDI.

That is one thing...
Another thing is that the GDI acceleration works differently as well.
A huge difference between XP and later GUIs (say 'Aero-based') is that the later ones are designed for GPUs, and basically run on D3D9.
This means that they assume your video card has 3d texturing capabilities and zbuffering.

You see, in early days, video memory was expensive, so you often didn't have more video memory than what was visible on the screen, at least in high resolutions and high-colour modes.
This meant that everything had to be drawn directly on screen, because double-buffering was not an option.
So to solve the z-order overlapping, the GUI framework kept track of bounding rectangles of each window (and in Windows, every component is a 'window', also buttons, checkboxes etc) and their z-order, in a tree-structure.

Using this tree, the framework could determine exactly which parts of which windows were visible, and which parts were not, and it would redraw only those parts of the windows, directly onto the screen.
You have probably seen this in action: when you drag a window quickly, you 'invalidate' the rectangles underneath, but they do not get redrawn instantly. You'll see remnants of your dragged window there, until the OS has enough time to redraw everything, and the underlying controls 'snap' back into place. Or of course, if the underlying application froze, it can no longer redraw, so its window remains corrupt.

By the time Vista came along, even the simplest integrated GPUs had basic Direct3D 9 acceleration capabilities, and videomemory was not an issue anymore either. You no longer wanted flickery-teary GUIs, you wanted smooth, solid GUIs with double-buffering and v-sync.
So, Microsoft dropped the old tree-of-rectangles, and instead let the GPU solve it. It's very elegant really:
Each window gets its own offscreen video buffer, basically a texture. The desktop is 'composited' by rendering each window as a textured quad, with the z-value of that window. The zbuffer will then automatically handle the z-order for you.

A huge difference in this approach is that overlapping windows no longer invalidate eachother, because they are not physically overlapping the offscreen buffers, and their contents do not get corrupted. This means that there is a lot less redrawing going on.
This is the main reason why Windows Vista got away with no GDI-acceleration so well: sure, it had to redraw components on the CPU, but it didn't have to do it all that often.
There was a catch though: because CPU-access to GPU-managed buffers is expensive (contention issues and all that), Vista had both a system memory and a video memory buffer for each window. The CPU could update the system memory buffer, and it was then staged to the GPU when done.

With Windows 7, Microsoft reintroduced GDI-acceleration. However, it worked in a completely different way from how it was implemented in XP and earlier.
It built on the Vista system, but removed the need for the system memory. Instead it used 'aperture memory' (you know the AGP aperture? It doesn't really have a name for PCI-e, but the idea is the same: memory that is shared by CPU and GPU). This means that the GPU can now draw directly to the backbuffers, opening the possibility of hardware-acceleration once more. It also means that you don't need a texture in video memory if you already have one in aperture memory, so Windows 7 is more efficient than Vista with its memory usage.

However, only a few things are actually GPU-accelerated. Mainly blits, alphablend, colorfill and font rendering (ClearType). XP had all sorts of operations such as line-drawing, rectangles, circles, polygons etc. These are not accelerated because GPUs use a very different way of rendering than what is required for these old bitplane-based operations (then again, modern CPUs can do these very quickly, so it may not even be worth it to set up specific commands for the GPU, which takes a lot of overhead). Which is why Direct2D was introduced: a new API which supports rendering operations that map nicely to GPU operations.

Another thing I seem to recall from GDI in Windows 7 is that they made GDI asynchronous. That is, drawing operations from different GDI contexts can overlap to speed up processing. I cannot find a reference to that at the moment though.

Anyway, TL;DR: There's a difference between 'GDI acceleration' and 'GDI acceleration'.

Interesting thanx! Imho the results of all these changes in 2D "acceleration" approach seems to be not that better for a desktop experience. I actually feel a 9x gui being "more reactive" that the last time I tried a modern CPU/GPU/OS. I mean, all these smoothness in recent os seems to be far from be "free" on processing power if we compare what we feel changed in terms of effects.

Windows 98's UI was meant to be useable even on ISA graphics cards, so it is VERY light on bus bandwidth. That is why it uses so many "XOR" effects for selection rectangles and moving windows, since then it doesn't have to read the screen contents to restore them when moving (another identical XOR operation restores things to the way they were) - these are fast even on non-accelerated ISA cards.
Once you start enabling effects, though, Windows 98 suddenly becomes choppy. Showing a window's contents while dragging doesn't feel very fluid even on my Duron. Windows 98's UI couldn't dream of rendering all the eye candy Windows Vista and above can in such a fluid manner even with today's computing power.