https://bugs.winehq.org/show_bug.cgi?id=39421
--- Comment #5 from Jonas Maebe jonas.bugzilla@gmail.com --- (In reply to Stefan Dösinger from comment #4)
Does the game draw to the front buffer?
Yes, I think the game blits to the frontbuffer:
trace:ddraw:ddraw_surface7_GetSurfaceDesc iface 0x16c160, surface_desc 0x33fb94. trace:ddraw:ddraw_surface7_GetSurfaceDesc Returning surface desc: trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_COMPLEX DDSCAPS_FLIP *DDSCAPS_FRONTBUFFER* DDSCAPS_PRIMARYSURFACE DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_VISIBLE DDSCAPS_LOCALVIDMEM
And all blits go that same interface: trace:ddraw:ddraw_surface7_Blt iface 0x16c160 ...
So you indeed would get the same effect as with my glFlush() clamping patch if you would queue them, unless you'd also associate a timer with them and flush anyway if within 1/18th of a second no new flush/blit has a arrived. The overhead of instating and removing so many timers all the time may also be significant though, especially with such short timeouts (although if you don't mind some delayed updates occasionally, you could increase their timeouts).
The only other alternative solution I can think of would be to add dirty rects (not "direct rects" as I mistakenly wrote above) handling, so that not the entire screen is flushed every time when only parts have been updated.