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

[Paul Gofman]

On 11/14/19 17:41, Henri Verbeet wrote:
> On Thu, 14 Nov 2019 at 15:47, Paul Gofman <gofmanp at gmail.com> wrote:
>> On 11/13/19 21:16, Paul Gofman wrote:
>>> Yes, the window handle is actually valid, as well as dc. Yet
>>> wined3d_context_gl_set_pixel_format() called from
>>> wined3d_context_gl_init() fails. The failure comes from winex11.drv,
>>> create_gl_drawable() fails through create_client_window(), which in turn
>>> gets NULL get_win_data() and refuses to create the data here. This is
>>> some (WS_POPUP | WS_SYSMENU) window created with 1x1 size which never
>>> changes, and looks like it never get shown. It does not look like the
>>> application is serious about trying to display something with it, as
>>> nothing seems to be missing on the display, yet it create d3d11 device
>>> there (while the game is mostly d3d9), draws a few frames and gives up.
>>> Do you think that wined3d should try to work around any possible reason
>>> when display driver fails to create opengl visual or can't set pixel
>>> format for some other reason? If the context is not supposed to be NULL
>>> in swapchain present under normal circumnstances, maybe we put ERR()
>>> there for the time being?
>>>
>> A bit of more details on this. The swapchain for which
>> swapchain_gl_present() fails is not a main device swapchain. The main
>> device swapchain is created for the other window and is fine. That
>> failing swapchain is created from dxgi factory
>> (dxgi_factory_CreateSwapChain).
>>
>> The creation of the swapchain succeeds, wined3d does not try to create a
>> GL context during that.
>>
>> Then it gets swapchain backbuffer (dxgi d3d11_swapchain_GetBuffer) and
>> renders something to this backbuffer as RTV.
>>
>> Then it calls d3d11_swapchain_Present() for this swapchain, and here is
>> when it tries to create GL context for the first time and fails in
>> SetPixelFormat.
>>
> 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?