user32: Track the number of GL surfaces for a window rather than the pixel format.
stefandoesinger at gmail.com
Mon May 12 03:13:57 CDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
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
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/
-----END PGP SIGNATURE-----
More information about the wine-devel