http://bugs.winehq.org/show_bug.cgi?id=5535
--- Comment #74 from Stefan Dösinger stefandoesinger@gmx.at 2011-06-27 10:41:21 CDT --- (In reply to comment #73)
Thanks for taking a look. What do you propose should happen to this bug? At the very least I suggest changing the title to reflect the GDI running out of handles issue that it seems to focus on (the current summary is far too vague).
I'm not sure. The GDI object limit is intentional I think. Trying to fill the vidmem with surfaces is the game's doing, that won't be fixed.
I guess the way to fix this is to rewrite the GDI renderer not to use a DIB section for every surface, only if it is a primary surface or the app calls GetDC. On the other hand Alexandre once said the software ddraw implementation should use gdi for blitting instead of its own implementations, which means we need a DIB section everywhere.
Either way it is a tricky situation and would need a lot of work. Honestly I'd prefer to ignore it and let people force the video memory size lower. We cannot limit the vidmem for apps using ddraw.dll in general because some opengl apps use ddraw to figure out how much video memory the GPU has.
It looks like comment 65-67 describes graphical glitches occurring with DirectDrawRenderer=opengl - that sounds like it should be a separate bug report.
Yes. I think the problem is that wined3d can't read the color keyed surface contents back. The game backs up the old content of the backbuffer before it draws a sprite, and when it moves the sprite it draws the old contents back rather than redrawing everything.