It was confusing before since it made it seem like it might use the outer
window, while in fact the document is unchanged on native. Now the "new"
doc is used for navigating, since it's already checked to be the same as
the iframes_doc (but that test fails in wine and is todo_wine).
The idea is to reuse the existing code to handle SRVs, which simplifies the GL
code and essentially allows the Vulkan code to work "for free" (which is to say,
by writing this patch, rather than by adding support for flat textures to the
Vulkan renderer.)
This is a large patch; it consists the following parts:
* Create identity SRVs for d3d 1-9 textures. Store those in
state->shader_resource_view instead of in state->texture.
* (Re)use wined3d_context_gl_bind_shader_resources() instead of state_sampler()
to bind them.
- Introduce code to that function to handle FFP textures.
- Bind the sRGB texture if necessary in wined3d_shader_resource_view_gl_bind.
* (Re)use context_gl_load_shader_resources() instead of
context_preload_textures() to load them.
- Introduce code to that function to handle FFP textures.
- Load the sRGB texture if necessary.
- Port the SRV/RTV feedback loop check from context_preload_textures().
* Invalidate STATE_GRAPHICS_SHADER_RESOURCE_BINDING in places that now need to
account for texture binding being guarded by that state instead of
STATE_SAMPLER.
Transitioning the remaining users of STATE_SAMPLER to
STATE_GRAPHICS_SHADER_RESOURCE_BINDING, and removing STATE_SAMPLER, is left
for future patches.
Allow us to avoid grabbing a temporary reference. This becomes a problem with
the next patch, where we would otherwise grab a reference while a texture is
being destroyed, and hence destroy it twice.
Currently we invalidate STATE_SAMPLER whenever an SRV is bound, and hence rely
on sampler() to do this for us, which is a bit obscure and won't work with the
next patch.
The tests show that the first argument must not be null, that the handle
returned via the fourth argument is not an HTHEME, and that that handle
can be passed to CloseThemeFile without error.
The std handles gotten from GetStartupInfo are only set when
process was created with STARTF_USESTDHANDLES flag.
And yes, Ansi and Unicode versions reset the std
handles to a different value.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Only allow std handle inheritance when:
- either bInherit flag of CreateProcess is TRUE,
- or child process is in CUI subsystem and STARTF_USESTDHANDLES is no
used.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>