-----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.)