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.
Similar to surface_prepare_system_memory(). In the long term we'll probably
want to move the whole location management to resource.c and unify buffers and
textures there.
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 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().
The old condition happened to work, because SFLAG_INTEXTURE was not
set(we're loading it), and neither was SFLAG_INDRAWABLE(otherwise
INTEXTURE would be set too). If the fbo INDRAWABLE == INTEXTURE is
replaced by INDRAWABLE == INSRGBTEX this doesn't hold true any longer
because SFLAG_INDRAWABLE is set, but not used because the drawable
readback is never used for fbos.
FBO stretchrect marks SFLAG_INDRAWABLE up to date, which currently
also marks SFLAG_INTEXTURE up to date. However, this will change when
we enable rendering to the srgb copy, in which case the drawable could
be equal to the srgb copy, not the rgb copy.
This prevents for example a d3d9 depth stencil from being destroyed when it
has no external references but is still in use by the device/stateblock. A
nice side effect is that it simplifies handling of "implicit" surfaces like
the frontbuffer and backbuffers, as well as the forwarding of reference counts
for surfaces that are part of a texture.
The MSDN is not totally correct: A8R8G8B8 and A1R5G5B5 also allow GetDC. The
main differences that have to be filtered out in d3d9.dll are GetDC on
A8B8G8R8, X8B8G8R8 and P8.
Passing NULL to glCompressedTexImage2DARB() doesn't work particularly well
when both client storage and PBOs are enabled. Also, two years is long enough
to give driver developers a chance to fix the bug this was supposed to work
around.
Stefan Dösinger