http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com 2013-09-24 18:14:55 CDT --- Created attachment 46065 --> http://bugs.winehq.org/attachment.cgi?id=46065 wined3d: Avoid nested context_acquire calls when handling onscreen surfaces.
I can reproduce the problem by manually forcing backbuffer offscreen rendering. The attached patch fixes the issue for me, can you test it?
The specific issue with this that the blit from the shadow front buffer to the real front buffer first acquires a context to draw to the real front buffer. This context has render_offscreen set to false. Then the source surface - an offscreen render target - is loaded, which in this case means transfering it from the WGL backbuffer to a texture. For this purpose a context is acquired by surface_load_fb_texture with the source as its target. The GL context is the same, but render_offscreen is set to true. Since context_release doesn't restore the previous setting, the following draw to the WGL frontbuffer fails.
The issue doesn't just affect render_offscreen. If the application uses multiple swapchains, surface_load_fb_texture(), surface_blt_to_drawable() and read_from_framebuffer() could activate an entirely different GL context.
The attached patch resolves this by avoiding calling preload with a render-target specific context set. This is somewhat ugly. Preload requires the caller to set up a context, so it shouldn't modify the context in some cases. Yet it has to, because the caller cannot know that it has to read from or write to a onscreen drawable.
A better solution may be to restore the previous context and its properties after those three calls. I'll investigate this option tomorrow. A third option is to make context_release able to restore the old context, but I think this is an overkill. Except for those 3 functions, there shouldn't be a need for nested context_acquire calls ever.
(The "if (0)" in arb_program_shader.c is a workround for an unrelated problem I ran into. I'll submit a proper fix for this issue tomorrow.)