On 27/11/2018 21:11, Henri Verbeet wrote:
On Tue, 27 Nov 2018 at 23:00, Axel Davy davyaxel0@gmail.com wrote:
On 27/11/2018 19:30, Henri Verbeet wrote:
you're doing buffer swaps on a separate thread anyway though, we can also just block in __wine_present_native_drawable(), instead of
You mean wait the buffer you send gets released/presented ?
That would require one thread per presentation.
Per swapchain, but yeah.
buffers can be released out of order, and after several presentations, thus you'd need several threads per swapchain if you block.
For example if you do triple buffering, one buffer will get released after one screen refresh, while you have done hundreds of presentations meanwhile (if we imagine 1000 fps toy app).
It could be done I guess (though it's not what nine does currently).
Can you think of any current window system (MacOS ?) that would benefit from this approach ?
Well, it would avoid the callback. I personally don't care that much about avoiding it, but it seemed to be one of your main concerns.
Ultimately, the choice is yours, as you get to accept the code. I won't bother write a code a certain way if you won't merge with that way.
spinning on __wine_present_is_drawable_released(). If it needs to be asynchronous though, a callback on completion/idle really isn't that Present specific. If the platform only provides a synchronous API, Wine can just call the notification callback itself on completion.
Sure you can implement a specific callback that would call a generic callback. It's an implementation choice indeed. I believe it would make the code more complex to do that way though for the user of the API (need to handle the multithreading part of the callback).
We made a few mistakes for Nine that caused the code to be a bit more complex that what it could have been.
The API I suggested would, I believe, avoid some of these mistakes and results in the simplest code.
From Wine's point of view, one of the things we care about is not exposing internals. Another is API surface. I.e., all other things being equal, exposing one entrypoint would be preferred over exposing 4. I'm not sure I see the added complexity over using Present directly though?
Then from that point of view, Nine would do with only one function to get the drawable attached to a hwnd, and the client rectangle on it (dc_rect).
From that Present can live in Nine.
From what I understand, the Vulkan and gl have few entry points, but return a vtable with a lot of functions.
Couldn't we imagine the same here for Present ?
(And note that if you ignored the msc, you could implement __wine_present_native_drawable() using a regular blit as well.)
You wouldn't get tear free then :-). You can get that even without vsync if you want - basically triple buffering (we have option for that).
Sure. The point was that the interface isn't much more than a blit + sync control.