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

[Henri Verbeet]

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.

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

> > 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?

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