user32: Track the number of GL surfaces for a window rather than the pixel format.

[Alexandre Julliard]

Ken Thomases <ken at codeweavers.com> writes:

> I already explained.  In the multi-threaded case, one thread can still
> be using an old surface after another thread released it and created a
> new one.

It can't be using an old surface unless you introduced the concept of
multiple surfaces in the first place... If the API is only, say,
wglSetPixelFormatWINE, then the change is considered instantaneous, and
threads that try to use the old format get an error, or get ignored.

Obviously, in the driver implementation, it may require you to recreate
an X11 window, and possibly keep the old X11 window around to prevent
crashes, but that doesn't mean that the concept of multiple active
surfaces needs to become part of the exposed API.

> Beyond that, although I'm not aware of a case where an app uses two
> D3D devices to target the same window, I'm also not seeing anything in
> the docs which says it's not allowed.  For example,
> IDirect3DSwapChain9::Present() takes an hDestWindowOverride parameter
> which causes that particular present to target a window that was
> previously unrelated to the swapchain.  I see nothing in the docs that
> suggest there's a limitation on which window you can use (other than
> that it be visible or top-level).  No error code meaning "invalid
> window" or "window format mismatch".

Maybe more test cases would be in order then. The concept of supporting
multiple active surfaces clearly raises a number of questions, and so
far it seems the answer is always "we don't know because no app ever
does this". So it feels to me like a solution in search of a problem...

-- 
Alexandre Julliard
julliard at winehq.org