[PATCH] wined3d: Avoid crash in swapchain_gl_present() if context could not be acquired.

Henri Verbeet hverbeet at gmail.com
Thu Nov 14 09:23:42 CST 2019


On Thu, 14 Nov 2019 at 18:22, Paul Gofman <gofmanp at gmail.com> wrote:
> On 11/14/19 17:41, Henri Verbeet wrote:
> > I think that makes sense, although it's still not entirely clear to me
> > why setting the pixel format fails. As for fixing the issue,
> > wined3d_context_gl_init() should probably take the same approach as
> > wined3d_context_gl_set_gl_context(), or perhaps things can be
> > reordered in a way that wined3d_context_gl_init() can simply call
> > wined3d_context_gl_set_gl_context().
>
> But the application is trying to present a swapchain into the window it
> specified, the resource is onscreen (if we imagine that it is going to
> draw something in some other case with a visible window, as here the
> window is 1x1 and invisible). Does it make sense if we create another
> invisible window instead and present something to the drawable obtained
> from it?
>
Somewhat, in the sense that it gives us the option of using e.g.
(gdi32) BitBlt() to still get the contents into the target window, if
we really needed to.

That isn't entirely the point though. Part of the issue is that the
behaviour for creating a new context should be consistent with the
behaviour for reusing an existing one. Another part is that for better
or worse, the model we currently have is that provided OpenGL works at
all, context_acquire() isn't supposed to fail. It may make sense to
rethink that, but we have a lot more context_acquire() calls besides
the one in swapchain_gl_present().

The background is that the target window can go away at any given
point, and D3D is supposed to keep working when that happens. Modern
versions of OpenGL/GLX can make a context current without a drawable,
but originally the drawable was required. Provided FBOs are available
current wined3d always renders offscreen and only needs an onscreen
context for Present(), but in the past that was not the case either.
(I.e., think Opengl 1.x or 2.x and "backbuffer" ORM.)



More information about the wine-devel mailing list