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

[Alexandre Julliard]

Ken Thomases <ken at codeweavers.com> writes:

> On May 7, 2014, at 4:57 AM, Alexandre Julliard wrote:
>
>> Sure, but IMO if the driver needs this it's doing something wrong. Maybe
>> I just don't understand what you are trying to do, but the notion of an
>> arbitrary number of surfaces per window doesn't make any sense to me.
>
> I'm writing a WGL extension with a function for creating surfaces.
> There's one implicit for WGL when the app sets a pixel format on a
> window, but we want wined3d to create separate ones to avoid messing
> up externally visible state.  Wined3d may create a surface for a
> window, use it, and then tear it down.  However, other threads may
> still have a DC referencing that surface and have a context current on
> it.  They will eventually clear that up when they next call into
> wined3d, but there's an indefinite period before that happens.
> Meanwhile, the first thread may create a new surface for the window.
> Etc.
>
> Each of these surfaces may have different pixel formats.  In the X11 driver, a different pixel format implies a different FBConfig and a different visual, so requires a new X window.
>
> Yes, there's a question about what happens if multiple surfaces are
> actually being used for rendering simultaneously.  Only one can be
> seen at a time, so what's the point, right?  In my current patches,
> the most recent one created is in front and visible.  I've got plans
> to make it so that the one most recently made current for a context
> will be in front.

I don't see why D3D would need anything like that. Do you really need to
be able to set a new pixel format but still draw with the old one and
expect the output to be visible?

It seems to me all you really want is to restore the pixel format after
D3D has used it, to avoid messing up WGL. This may require the driver to
maintain a separate D3D pixel format, and possibly two surfaces, or
maybe one surface recreated as needed once the app uses WGL again, but I
don't see why it would justify adding an API to manage an arbitrary
number of surfaces. What are the use cases for this?

-- 
Alexandre Julliard
julliard at winehq.org