This allows the swapchain to know what depth format its window contexts have to see if the
requested depth format is compatible or a FBO fallback is needed, and it will be needed to
set the onscreen format to the requested auto depth stencil format instead of the
let's-hope-it-fits D24_UNORM_S8_UINT format.
Updating a texture while it is attached to the currently bound FBO is
something GL implementations tend to get wrong. NVIDIA fails at
glTexSubImage2D(), fglrx and Mesa with glTexImage2D(). I'm afraid to try what
happens on OS X. Fortunately we never use glTexImage2D() while a texture is
attached to an FBO, so we only need to care about glTexSubImage2D().
Just make sure the texture is allocated, so we have something to attach. Note
also that context_apply_attachment_filter_states() runs under the GL lock, so
preloading resources is actually unsafe there.
Currently callers of this function are responsible for setting the draw buffer
correctly, but they don't do a very good job:
- swapchain_init() sets the draw buffer to GL_BACK if there's a back buffer,
even though the context's target is always the front buffer.
- swapchain_create_context_for_thread() depends on (eventually) being called
by FindContext().
- create_primary_opengl_context() and
IWineD3DSwapChainImpl_SetDestWindowOverride() don't bother setting a draw
buffer at all.
Just marking the draw buffer dirty lets the context management sort it all
out, and is much simpler.
Casting the container to "IWineD3DSwapChainImpl *" is always safe when
SFLAG_SWAPCHAIN is set on the surface. Most callers don't have a real
need for the swapchain, and end up calling GetContainer() just to pass
it to surface_get_gl_buffer().
The background on this is that some applications use OpenGL and DirectDraw/Direct3D on
the same thread, typically using OpenGL for rendering and DirectDraw to get
the amount of available video memory. This means that we might replace the
application's current GL context with one with a completely different state,
but also that our current GL context might not be what we think it is.
The idea here is that we can restore the thread's current GL context on
context_release() if it doesn't correspond to the current wined3d context on
context_acquire().
Some version of Mesa will claim the window system provided framebuffer is
incomplete when using indirect rendering, although the framebuffer objects
spec says this can never happen. Printing an ERR instead of crashing should
make it clearer that this isn't a wined3d problem.
Apparently it's valid to use a D3D device after its window is destroyed.
OpenGL isn't always so forgiving, so this patch is a first step to avoid
making GL calls on a context without window.
Stefan Dösinger