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

[Axel Davy]

On 27/11/2018 17:23, Henri Verbeet wrote:
> I should note that winex11 is slightly outside my area of expertise;
> Alexandre is the one you'll ultimately have to convince. For what it's
> worth though:


I added Alexander as CC. What is your point of view, Alexander ?


>
> On Fri, 23 Nov 2018 at 23:25, Axel Davy <davyaxel0 at gmail.com> wrote:
>> On 23/11/2018 17:36, Henri Verbeet wrote:
>>> What I had in mind would be something similar to the following:
>>>
>>> __wine_present_native_drawable(HWND window, ULONG_PTR drawable,
>>> unsigned int flags,
>>>           const RECT *src, const POINT *dst, UINT64 msc, UINT64 divisor,
>>> UINT64 remainder);
>> Do you have a similar platform API (Mac ?) you would like to cover with
>> this interface ?
>>
>> I think passing the native drawable directly is not a good idea (because
>> it requires to set up a callback system to get the updated status of
>> that drawable).
>>
> I don't know, do you need to? I don't think callbacks are bad per se though.
>
>> Thus I would suggest an interface in the spirit of:
>>
>> __wine_present_native_drawable(HWND window, wine_present_drawable
>>    *wine_drawable,
>> unsigned int flags,
>>           const RECT *src, const POINT *dst, UINT64 msc, UINT64 divisor,
>> UINT64 remainder);
>>
>> wine_present_drawable *
>> __wine_present_make_wine_drawable(ULONG_PTR drawable)
>>
>> __wine_present_process_events(bool block_if_no_event); // basically a flush + process events
>>
>> /* Those wouldn't process events, only check states */
>> __wine_present_is_drawable_released(wine_present_drawable *wine_drawable);
>> __wine_present_is_drawable_presented(wine_present_drawable *wine_drawable);
>> __wine_present_drawable_get_last_presented_msc(wine_present_drawable *wine_drawable);
>> __wine_present_release_drawable(wine_present_drawable *wine_drawable);
>>
>> and have then multithread safe ie multiple threads can call the functions without blocking.
>> For example I can have a thread waiting with __wine_present_process_events(true),
>> while another thread does __wine_present_native_drawable.
>>
>> Would that work out ?
>>
> 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.

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.

Yours,


Axel Davy