Ken Thomases ken@codeweavers.com writes:
On May 8, 2014, at 3:18 AM, Alexandre Julliard wrote:
It can't be using an old surface unless you introduced the concept of multiple surfaces in the first place...
You don't even acknowledge the need for multiple surfaces _serially_? That wined3d might create a surface on a virgin window and then destroy it, and then later create another one?
It's probably a question of terminology. To my mind, there is one place in the window where you can render stuff, using a specific pixel format.
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.
The concept of supporting multiple active surfaces clearly raises a number of questions, and so far it seems the answer is always "we don't know because no app ever does this". So it feels to me like a solution in search of a problem...
That's exactly backward. The problems are real and known. My work solves them. You are hypothesizing that my work will cause problems which would only happen if apps did what "no app ever does".
No, that's not what I'm saying. I'm sure your approach is solving problems. My point is that the mechanism you are introducing raises new questions, like what happens when two surfaces are active at the same time. You are saying that this can be left undefined because no app ever does it, which leads me to wonder whether the API shouldn't better reflect what apps actually do.