Ken Thomases ken@codeweavers.com writes:
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 see why D3D would need anything like that. Do you really need to be able to set a new pixel format but still draw with the old one and expect the output to be visible?
It seems to me all you really want is to restore the pixel format after D3D has used it, to avoid messing up WGL. This may require the driver to maintain a separate D3D pixel format, and possibly two surfaces, or maybe one surface recreated as needed once the app uses WGL again, but I don't see why it would justify adding an API to manage an arbitrary number of surfaces. What are the use cases for this?