It's actually the opposite, modern mode uses gpu for compositing, classic modes uses cpu, and any gpu would beat cpu handily in that task including integrated ones.

Unless, you didn't install the correct driver and used standard vga driver, or like in a vm which doesn't provide gpu acceleration.

Classic mode does not use compositing at all, but the drawing routines of GDI etc were hardware accelerated already. Keeping a buffer around for every window for compositing could become a big performance problem and was part of the reason why Vista was considered slow. Mac OS X had this problem too.

I was curious myself, this link is a bit of an introduction to the mess:

https://learn.microsoft.com/en-us/windows/win32/direct2d/com...

"GDI is hardware accelerated on Windows XP, and accelerated on Windows 7 when the Desktop Window Manager is running and a WDDM 1.1 driver is in use. Direct2D is hardware accelerated on almost any WDDM driver and whether or not DWM is in use. On Vista, GDI will always render on the CPU."

Here's a more honest and direct introduction than Microsoft itself could wrote: https://forums.cockos.com/showthread.php?t=55358

Especially follow the YouTube links demonstrating the problem: https://www.youtube.com/watch?v=ay-gqx18UTM https://www.youtube.com/watch?v=ToFgYylqP_U

GPU doesn't nessisarily mean less lag depending on buffers and implementation.

I know this. Heard it a bunch. The composited path was still slower.

Well, my experience was modern mode is way more responsive, and I've convinced at least 5 friends on sight.

The parent post refers to responsiveness, not throughput. Even if the GDI was fully accelerated, the compositor adds additional input lag because it has to sync with the monitor's refresh rate whereas without DWM the monitor displays whetever is on the framebuffer. The drawback is that you get tearing and damage artifacts (like the classic crash window[0]).

[0] https://mrdoob.com/lab/javascript/effects/ie6/

Not sure if this is exactly related, since it's beyond my understanding, but it seems game devs have been struggling to get things drawn on the screen at the expected time. (The speaker says things were much more straightforward on the Amiga. Progress works in funny ways!)

https://www.youtube.com/watch?v=n0zT8YSSFzw

That is a different thing (i've seen the issue in my own games), it is really about how even if the game updates at 60Hz, producing stable 60fps and shows on a 60Hz monitor with vertical synchronization (vsync) enabled you can occasionally have some "stuttering" (IIRC he calls them "heart beats" in the article the video is about).

The main reason is that your game time and the monitor's "time" are not really progressing in sync and even with vsync you are actually reacting on what the monitor did in the "past". This is why it isn't a problem on fixed platforms like the Amiga since you more or less know how fast the system is and can simply use vsync for game updates too (in other words make the game dependent on the framerate and just ensure the framerate is more or less constant, which is easy on fixed hardware but much harder on something like the PC).

FWIW this is still a problem, but at least a "hack" that has become a bit common since the video and article were published (and Croteam also did) is to "smooth out" the time progression by averaging the time deltas of the last few cycles. This doesn't fix the core problem but it makes the "heartbeat" less likely to happen and be noticeable at the cost of -mostly imperceptible- drift between game time and real time (that you can always reset if it becomes too large anyway).

I've spent the last few days messing with Linux in both VirtualBox and VMWare and I found that disabling 3D acceleration leads to ~2x faster boot, and disabling desktop compositing (in the Linux guest) leads to 5x less lag when moving things around on screen.

I was surprised, because I thought using 3D acceleration and compositing would be faster.

Also, I run the VM at half res and used DPI workaround (.manifest file) to let Windows scale the VM instead of VirtualBox (VirtualBox scaling is very slow for some reason).

Linux in a VM doesn’t behave like Linux on bare hardware, and graphics acceleration in particular is a house of cards. You can’t draw any real conclusions from this.

> in my experience seemed to

You lost me there. There needs to be real numbers measured, or the effect never existed.

The whole "in my experience" arguments do contain some truthful anecdotes, but "from my experience" they're difficult to filleter from all the FUD, placebos and snake-oil.

So try it yourself, on bare metal with Win7, and you can see if my subjective experience is replicated.