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

[Henri Verbeet]

On 12 May 2014 07:06, Ken Thomases <ken at codeweavers.com> wrote:
> On May 9, 2014, at 5:34 AM, Alexandre Julliard wrote:
>> If multiple users try to set a different format on the window at the
>> same time, there's a need to arbitrate that. Your solution is to create
>> multiple surfaces, but then this moves the problem to arbitrating which
>> surface is the "real" one, i.e. the one that actually puts something on
>> the screen. Because in the end there's only one visible window surface.
>>
>> Obviously under X11 we need to create a new drawable because the format
>> is set at creation time, but that doesn't necessarily have to be
>> something that wined3d knows about. Conceptually it's still the same
>> window surface.
>
> Actually, I believe it is something that wined3d needs to know about.  Commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 introduced a number of regressions.  One of them was a performance drop.  This drop happens even in the case where nothing else sets a pixel format on the window.  The performance problem comes just from wined3d having to check if there _might_ have been contention over the pixel format – if the app might have changed it since the last time wined3d was entered.  To avoid that check, each swapchain must know that the OpenGL context it uses is attached to a private drawable that is not shared either with WGL nor with other swapchains.  It has to know that once it sets the pixel format on its private drawable, nothing else can change it.  (This is the purpose of the hdc_is_private and hdc_has_format flags introduced with commits 27287382 and f3aa4812.)

Well, sort of. There can be multiple D3D devices on the same window,
and drawing with those should work, although I'm less sure to what
extent the output of a such a setup is supposed to be defined. This
needs tests. Something similar applies to drawing with WGL and D3D to
the same window.

The internal wined3d interface is context_acquire()/context_enter()
and context_leave(). For the purpose of this discussion, and ignoring
the bit about switching a window / drawable to fullscreen mode, a
"context" mostly consists of a DC, WGL context, pixel format, and swap
interval. What wined3d needs is for context_enter()/context_leave() to
be fairly fast, and invisible to anything executing outside of a
context_enter()/context_leave() pair. Whether such a set of state is
called a "surface", a "context", or something else is perhaps mostly
terminology. (Although I should note that "surface" already has a
different meaning within wined3d, so in that regard it's perhaps not
ideal.) Similarly, wined3d doesn't really care what the driver's
implementation of all this looks like.