https://bugs.winehq.org/show_bug.cgi?id=39421
--- Comment #7 from Jonas Maebe jonas.bugzilla@gmail.com --- (In reply to Stefan Dösinger from comment #6)
I don't see how we can do partial flushes. glFlush doesn't take any arguments.
I guess it would boil down to implementing double buffering ourselves: always keep a copy of the previous image in VRAM, and then composite that one (on the card) with textures created from the the new partial blits (which come from system memory and which only cover part of the screen).
There should be no need for transfers from VRAM back to system memory in this scenario, nor for any dirty rects testing by Wine, as the blits tell you exactly where the dirty rects are. Unless, of course, you have to take into account that the frontbuffer may also be modified by other means than ddraw blits. However, since forcing the game to always use ddraw blits resolves the speed issue on Windows, I guess this can somehow be detected/known.
One idea that has been floating around since a long time is to have a thread in wined3d that draws the front buffer to the screen every 1/60th second, and otherwise we don't do anything special about front buffer modifications. I guess this would fix this game here, but it isn't really trivial to implement.
I can imagine.