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

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-05-12 07:06, schrieb Ken Thomases:
> Also, it is my understanding – and I hope that Henri, Stefan, or 
> Matteo will correct me if I'm wrong – that swapchains are
> independent sets of backbuffers.  An app can have more than one.
> Each swapchain has a separate pixel format.  The app can issue a
> bunch of drawing commands to each and they should be independent.
> It can draw a circle in one and a square in the other.  It can then
> "present" either swapchain and only that swapchain's rendering will
> make it to screen.  It will show either a circle or a square but
> not a circle overlapping a square or the like.
Correct. There was a d3d tutorial that demonstrated this, but rendered
to two different windows. I cannot find it (many d3d9 tutorials seem
to be gone). This is also what happens when multihead d3d is used.

> It can then, of course, present the other or not or do it in the
> other order.
The "can" part is correct, but we don't know exactly what happens
because we don't have tests. I'd expect the second Present to
overwrite the output of the first.

Also note that in d3d the pixelformat is set on the backbuffer, not
the window. (present_parameters.BackBufferFormat). There's also the
display mode, which specifies a separate pixelformat for the screen
(again, not the window). There is a function to check compatibility
between screen and backbuffer formats. Usually D3DFMT_A8R8G8B8 is used
on backbuffers and compatible with D3DFMT_X8R8G8B8. R5G6B5 is
compatible with R5G6B5, and A8R8G8B8 is compatible with A8R8G8B8.

> I don't know how wined3d currently deals with the case of multiple 
> swapchains targeting the same window.  That is, how it keeps the 
> drawing commands and backbuffers of one independent from those of 
> another.
Based on the render target we know where the draw commands go to. For
the output see below.

> Using separate contexts works to some extent, but only until the
> OpenGL command buffer fills, at which point the drawing from one
> would be flushed to the backbuffer the contexts share. Wined3d may
> ignore this or maybe it uses FBOs or something for the backbuffers
> of secondary swapchains.  In either case, multiple surfaces offers
> an opportunity to improve the status quo.
We usually use FBOs to render to backbuffers. This can be disabled by
the user (HKCU/Software/Wine/Direct3D/AlwaysOffscreen, or by setting
OffScreenRendering = backbuffer), or when FBOs are not available. This
legacy mode is still used on some older drivers.

If two contexts share a window and we're not rendering to an FBO the
draw commands will interfere with each other. Currently we're using
this effect for multithreading support (when the application uses one
swapchain to render to one window, but renders from different threads.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTcILFAAoJEN0/YqbEcdMwCUIP/28XVdeE1nODKnI3iCqGkdWf
1jcGjOHDUPSeO/vZxSUkVUaCYj+QOsh+pNHZ3B+w+YDeByDjAYEzXiDTQCp8wpFF
2U9Kc3o0BNmSl3Fg44kv+UKa3IUqd0YNw7jvZBPoQGse6Tk/4av0+lbFsx004bst
kJLqVJk1ecdcmDp4v0MpSgEB56usiw/Wxarl6I6xMiw3kqqcse+0u/ZZO48ygkqS
JRfp/OCBmoGwzch1+KIBAkxnyPBGFCsJigMYFf3Nuu8YgIH6T1E+bCBwj9YkaPIf
CKUmTStSZGQQSTWiBsQE5X4QHGFyUoSOjmyMvqY1YnIx9KSLeK6+DbDwbQ4trpSg
hfWh6PXUsXTLix1ISD721HkRW8vrKrhAFVi17+q8CTIXu+3C1nyfVZzf46LzTTaC
bBob4JgH1tcUJXeagCmNEYcZhPj/ZqQK9Jkg6fypKzN1SMVYpW1Qive2Cbsl1qy2
Uh5hjIj7sA+05ldQhr8HBWKoV+bdlqVzxw0J+tsU8BeZU6CadF4HSq6402L9ytM0
WK/Nes2Nue+S0YBcXj+gUOq1eAWa5WT5n11x0h7yht83YW2ldJl0wfnAPlBQizGL
CyqevaKJvPbr9/6TDyzioGHP7GhBsOxS2Y9azwm5+5uDX5N8e845DrkTqRkbpYPd
yoCfloLQBaUnz/Pm473H
=E60k
-----END PGP SIGNATURE-----