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

[Ken Thomases]

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 know what happens on Windows if WGL and D3D are used simultaneously against the same window, or if two D3D devices or swapchains attempt to simultaneously target the same window.  The tests already show that using D3D on a window which has had a WGL pixel format set on it doesn't generate errors.  And we know that some games do that.  I just don't know if they actually make a context current or try rendering while D3D is in use.  The wined3d code certainly assumes that the app may have made a WGL context current before calling into it and goes to the trouble of restoring it before returning.

In any case, if D3D is used temporarily, then after it's done (on all threads) we'd like the window to be returned to a state as though D3D were never used on it.  If no WGL pixel format had been set, then it should have no surfaces and user32 and gdi32 should resume normal rendering.  If one had been set, then it should have just the WGL surface.

-Ken