LSS10999+RayeR: GDI is still pain, there 2 two reasons for this, first is that DIB driver is reading from GPU (when scrolling, it reads block from VRAM, moves pointer of x lines and writes it back). Second is that the DIB engine runs in PM16 and all operations crossing segments are super slow. Other drivers are solving this with HW blit, but in VESA is nothing like that. Solution can be shadow frame buffer in RAM and updating by one way copy to video ram. I’m already doing when emulating double buffering (on VMware), but shadow buffer is still in VRAM, but essence is similar. I can also implement BLIT in PM32 RING-0 (more important is PM32 than RING-0), resp. I can use existing code from HAL, but I think that reading operations from GPU are main bottleneck.

Fortunately, I made the things bit faster by is by implemented my own procedures for working with the mouse cursor, but GDI is still quite slow.

I've tested the newest version (v0.8.2025.53 special edition available for donators) on my ThinkPad X230 and DOS windows work quite well (even in windowed mode, tested only text applications) and window dragging/scrolling/shutdown animation are not as laggy as with VBEMP.
The update modes option from the tray icon worked fine and after performing it - 1366x768 resolution showed up correctly.

In 3DMark2001 SE with default installation settings I got... 241 points 😜 But all game tests did complete.

DX7/DX8/DX9 video tests in DXDiag are working, though of course, the cube spins somewhat slowly.

There are too many options in the installer and too many hardware I have...and not enough time to test everything 😒

I've also enabled the AVX hack, but llvmpipe still shows only 128bit.

JH64 wrote on Yesterday, 08:02:

LSS10999+RayeR: GDI is still pain, there 2 two reasons for this, first is that DIB driver is reading from GPU (when scrolling, it reads block from VRAM, moves pointer of x lines and writes it back). Second is that the DIB engine runs in PM16 and all operations crossing segments are super slow. Other drivers are solving this with HW blit, but in VESA is nothing like that. Solution can be shadow frame buffer in RAM and updating by one way copy to video ram. I’m already doing when emulating double buffering (on VMware), but shadow buffer is still in VRAM, but essence is similar. I can also implement BLIT in PM32 RING-0 (more important is PM32 than RING-0), resp. I can use existing code from HAL, but I think that reading operations from GPU are main bottleneck.

Fortunately, I made the things bit faster by is by implemented my own procedures for working with the mouse cursor, but GDI is still quite slow.

Did some tests with the new driver.
- It seems GDI performance is indeed weak. Explorer windows, as well as games such as Solitaire, draw much slower compared to VBEMP9x.
- Mouse cursor may flicker when the system is busy. I don't recall this happened with VBEMP9x, but probably related to GDI performance.
- Scrolling in WordPad may perform a bit better compared to VBEMP9x under some circumstances, but still very slow.
- The background darkening effect when opening the Shutdown dialog, however, does not differ much in drawing time compared to VBEMP9x.

I think this driver's memory test may not be a good idea for baremetal video cards, and better leave it disabled by default in such cases.
- With AMD video cards this will lead to the BSOD you mentioned, requiring the use of "NoMemTest"="1", when setting especially a 32-bit color resolution.
- With nVidia video cards the BSOD doesn't occur but the memory test can mess up the display the moment before Windows actually starts, if startup logo enabled. This is mostly harmless, though.

By the way, Direct3D does work with this driver, and can be tested with DXDIAG. The performance is far from ideal, however.

I just noticed another thing with the new driver, regarding issues with DOS boxes.
- DOS games that tries to change to a fullscreen VGA mode while in a windowed DOS box will fail and stuck in text mode. This includes starting the DOS game's executable directly.
- Making MS-DOS Prompt enter full screen will lead to a totally blank screen with only the text cursor visible, but works normally, as if it's just the text mode fonts were emptied. DOS games, if launched in this state, will work properly. Exiting the game will make text mode fonts visible again.
- The issue above also applies to "Exit to DOS" in the shutdown options. Exiting to DOS directly will lead to an empty text mode, but if I started a DOS game in a fullscreen "MS-DOS Prompt" then exits (which restores text mode), text mode will work normally upon exiting to DOS.

On the other hand, this breakage somehow avoided an annoying issue I'm having on a system that is using an nVidia video card, that it would cause the system to hang for a while, beep, then resume afterwards, whenever I open an "MS-DOS Prompt", and could also happen with certain programs invoked by installers in the background (without actual window). With this driver the issue doesn't happen. On systems with AMD cards this manifests as flickers (screen turning blank for a brief moment) without any hang/beep, and also doesn't happen with this driver.

EDIT: Okay, just read the CONFIG.MD and it seems this particular parameter (DosWindowSetMode) is responsible for controlling the modeset functionality. By default this is 0 so DOS programs cannot set mode, which also prevents any odd behavior that may happen (like nVidia cards touching the CRTC register).