[PATCH] Revert "include: Use the ARRAY_SIZE() macro in debug.h."

[Axel Davy]

On 27/11/2018 21:11, Henri Verbeet wrote:
> On Tue, 27 Nov 2018 at 23:00, Axel Davy <davyaxel0 at 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.