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

[Ken Thomases]

On May 8, 2014, at 3:18 AM, Alexandre Julliard wrote:

> 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...

You don't even acknowledge the need for multiple surfaces _serially_?  That wined3d might create a surface on a virgin window and then destroy it, and then later create another one?

> 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.

Or compete with the new pixel format causing pixel format thrashing, which is the status quo.

> 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.

What requires it is all of the bugs caused by the status quo.

The sole client of the new extension is wined3d.  D3D and wined3d allow multiple swapchains to simultaneously target the same window.  Each may use a different pixel format or swap interval.  Likewise, WGL may set a pixel format or swap interval on a window simultaneously being used for D3D.  In both WGL and GLX, the pixel format and the swap interval are properties of the drawable.  They currently conflict, causing various failures.  We need them to be independent so they don't interfere with each other.  Therefore, wined3d requires multiple drawables.

It may be theoretical that any app actually uses such multiple swapchains for rendering simultaneously, but as Stefan pointed out it's not theoretical that apps set up such swapchains.  In any case, in designing an API for the use of wined3d, I need to support what wined3d supports, even in theory.


> 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...

That's exactly backward.  The problems are real and known.  My work solves them.  You are hypothesizing that my work will cause problems which would only happen if apps did what "no app ever does".  If the presence of multiple surfaces causes such a problem, we'll then have an actual real world case and can debug and solve it.  Ideally, we'd do that debugging before the bulk of my work is actually committed, and some of our testers have indeed been helping me identify and debug issues with my patches.  So far, the existence of multiple surfaces has not been one of them.

-Ken