I recall a problem with some graphics cards (S3 ?) where certain video operations caused audio distrortion.
Something about the video driver busy-waiting on some accelerator register for too long, long enough to produce audible gap in the audio stream.

I think it was mostly VIA MVP3/4 boards that suffered from that

Grzyb wrote on 2023-05-05, 00:11:

I recall a problem with some graphics cards (S3 ?) where certain video operations caused audio distrortion.
Something about the video driver busy-waiting on some accelerator register for too long, long enough to produce audible gap in the audio stream.

I do get audio distortion on my Socket 7 computer with some 2D Windows games that tend to use GDI acceleration in 16-bit color mode but not when using 256 color mode. The same video card when installed on my Slot 1 computer works fine.

Other than that, I never had to lower the hardware acceleration slider.

As I've recently learned, if you want to get Need for Speed SE DirectX 2.0 version installed and running on faster versions of Windows 9X, you'll usually need to drop the slider down to at least 50%, but often completely disabling acceleration solves the issue more reliably.

Not Windows 9x, but Destruction Derby 2 won't run in hires mode on some XP systems unless you disable H/W acceleration.

I had a bunch of problems with GUI hardware acceleration. In some cases it will reduce performance, hide some screen modes in games, refuse to run some particular game or outright refuse to show desktop during boot sequence.

Reducing it one notch can fix black screen on some cards like S3 Savage.

I remember doing this for both audio and video acceleration, and in many cases it worked... though there were usually some compromises.

Does anyone here actually know what these sliders do?

Ozzuneoj wrote on 2023-05-05, 02:50:

I remember doing this for both audio and video acceleration, and in many cases it worked... though there were usually some compromises.

Does anyone here actually know what these sliders do?

I don't know how it works on Windows. But i worked on the Linux graphic stack in a previous job.
I can risk a guess, but not 100% sure.

On Unix/Linux, X.Org is a display server. Simplified, it has access to physical devices (screens/keyboard/mouse).
The display server listen for incoming connections (tcp or local socket).
The applications that must draw stuff connects to the display server. In standard desktop usage, the application connects to the display server running on the same machine.
The application send draw orders through this connection, using a protocol called X11. Orders like "create a window, draw a line or an image inside". But also more complex orders, like "blend this font with the background using alpha compositing".

When the server displays this on the screen, it must talk to the physical device : graphics card.

In the context of 2D graphics :
Roughly, in the un-accelerated mode, the CPU draws pixels one by on in the framebuffer.
In accelerated mode, the operations are drawn by the card itself. And the card often have magic tricks to accelerate things like drawing rectangles, filling a zone with a defined pattern. Line from point x0-y0 to x1-y1.
For example, a common optimization is copy the framebuffer content from here to here, when a window is moved on screen. (instead of clearing and re-drawing).

Moving the "Acceleration" slider down on Windows probably reduce the number of magic tricks used to draw stuff.
Less things handled by the card, more by the CPU. Less dependant on the card and its drivers, more dependant on the CPU.

See here for code example (for mach64 solid rectangle fill): https://gitlab.freedesktop.org/xorg/driver/xf … h64accel.c#L565
The driver talks to the card and asks it to draw a rectangle. The CPU could have done it by itself by accessing the framebuffer pixel by pixel. But this would have been much slower.

acl wrote on 2023-05-05, 17:18:

I don't know how it works on Windows. But i worked on the Linux graphic stack in a previous job. I can risk a guess, but not 100 […]
Show full quote

Ozzuneoj wrote on 2023-05-05, 02:50:

I remember doing this for both audio and video acceleration, and in many cases it worked... though there were usually some compromises.

Does anyone here actually know what these sliders do?

I don't know how it works on Windows. But i worked on the Linux graphic stack in a previous job.
I can risk a guess, but not 100% sure.

On Unix/Linux, X.Org is a display server. Simplified, it has access to physical devices (screens/keyboard/mouse).
The display server listen for incoming connections (tcp or local socket).
The applications that must draw stuff connects to the display server. In standard desktop usage, the application connects to the display server running on the same machine.
The application send draw orders through this connection, using a protocol called X11. Orders like "create a window, draw a line or an image inside". But also more complex orders, like "blend this font with the background using alpha compositing".

When the server displays this on the screen, it must talk to the physical device : graphics card.

In the context of 2D graphics :
Roughly, in the un-accelerated mode, the CPU draws pixels one by on in the framebuffer.
In accelerated mode, the operations are drawn by the card itself. And the card often have magic tricks to accelerate things like drawing rectangles, filling a zone with a defined pattern. Line from point x0-y0 to x1-y1.
For example, a common optimization is copy the framebuffer content from here to here, when a window is moved on screen. (instead of clearing and re-drawing).

Moving the "Acceleration" slider down on Windows probably reduce the number of magic tricks used to draw stuff.
Less things handled by the card, more by the CPU. Less dependant on the card and its drivers, more dependant on the CPU.

See here for code example (for mach64 solid rectangle fill): https://gitlab.freedesktop.org/xorg/driver/xf … h64accel.c#L565
The driver talks to the card and asks it to draw a rectangle. The CPU could have done it by itself by accessing the framebuffer pixel by pixel. But this would have been much slower.

Very interesting! Thank you!

In all my years of using PCs I've never really dug into what hardware acceleration for 2D actually accomplished, and this explains it very well in plain english.

I imagine that this is why sometimes on older operating systems (and with wonky drivers) you will move or close a window and the image of the window will get stuck on the background until something else is drawn in that portion of the screen. Something was attempting to optimize the workload but failed to do so accurately either due to hardware or software issue.

Good stuff! 😀

I remember when Computer Shopper was full of talk about how magical accelerated bit block transfers were. I miss those days, but I guess that's why I'm here and why I'm listening to my music on Winamp running on my windows 98 se machine...

There are windows sources floating around so you could look it up at the source.