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

[Henri Verbeet]

On Tue, 27 Nov 2018 at 20:31, Axel Davy <davyaxel0 at gmail.com> wrote:
> On 27/11/2018 17:23, Henri Verbeet wrote:
> > My main question would be "Why do you need that?" For example, event
> > processing should normally already be done by the application.
> > Somewhat similarly, __wine_present_make_wine_drawable() may make sense
> > if Wine would need to store some extra information along with the
> > native pixmap, but I don't think we do.
>
> Processing present events is not done by the application.
>
Sure.

> You have to set up a listener for the window to specify you want to
> listen to them,
> and use a callback. You use your own xcb queue, thus only you control
> when to treat the events.
>
> If you don't use a callback, you cannot know if/when the drawable was
> presented, and if released or not (which is pretty important to know).
>
> If you let nine/other user of the wine_present API get a callback, it
> will be pretty hard to make generic. Imagine another similar window
> system API doesn't work with callback ?
>
> If you handle the callback in wine_present, you are forced to store
> somewhere the presented/released information when handling the callback,
> which is why I suggested __wine_present_make_wine_drawable.
>
I don't think "released" is a Present term. (Do you mean "idle"?) If
you're doing buffer swaps on a separate thread anyway though, we can
also just block in __wine_present_native_drawable(), instead of
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.
(And note that if you ignored the msc, you could implement
__wine_present_native_drawable() using a regular blit as well.)

In terms of other platforms, we have Android/ChromeOS, Wayland, and
MacOS. Some of those could conceivably run Nine.