This reverts commit af3992374e530a037e650b45194f933c5406038f.
wine/debug.h is a public header, and ARRAY_SIZE() is not defined for external projects.
Signed-off-by: Andre Heider a.heider@gmail.com --- include/wine/debug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/wine/debug.h b/include/wine/debug.h index 066873a38a..fb0d6bb737 100644 --- a/include/wine/debug.h +++ b/include/wine/debug.h @@ -254,7 +254,7 @@ static inline const char *wine_dbgstr_vt( VARTYPE vt ) if (vt & ~VT_TYPEMASK) return wine_dbg_sprintf( "%s%s", wine_dbgstr_vt(vt&VT_TYPEMASK), variant_flags[vt>>12] );
- if (vt < ARRAY_SIZE(variant_types)) + if (vt < sizeof(variant_types)/sizeof(*variant_types)) return variant_types[vt];
if (vt == VT_BSTR_BLOB)
On Sun, 18 Nov 2018 at 20:56, Andre Heider a.heider@gmail.com wrote:
wine/debug.h is a public header, and ARRAY_SIZE() is not defined for external projects.
The change itself seems harmless enough, but the premise seems wrong. Headers in include/wine are private Wine headers; why do you need (or want) to include wine/debug.h?
On 18/11/2018 18:35, Henri Verbeet wrote:
On Sun, 18 Nov 2018 at 20:56, Andre Heider a.heider@gmail.com wrote:
wine/debug.h is a public header, and ARRAY_SIZE() is not defined for external projects.
The change itself seems harmless enough, but the premise seems wrong. Headers in include/wine are private Wine headers; why do you need (or want) to include wine/debug.h?
Hm, are they private? They're installed, and using wine's debug channels work just fine. Looking at the file, there're specific macros for !__WINESRC__ too, e.g. WINE_FIXME().
Apart from the debug channels, we use these too: toupperW() (unicode.h) wine_dlopen() (library.h), and I guess a few more.
Are the specific reasons to not expose those useful functions to external projects?
Regards, Andre
On Sun, 18 Nov 2018 at 21:19, Andre Heider a.heider@gmail.com wrote:
Hm, are they private? They're installed, and using wine's debug channels work just fine. Looking at the file, there're specific macros for !__WINESRC__ too, e.g. WINE_FIXME().
I think that's largely historic, we didn't use to define __WINESRC__ for tests and programs.
Apart from the debug channels, we use these too: toupperW() (unicode.h) wine_dlopen() (library.h), and I guess a few more.
Again, what are you doing exactly that you need those?
Are the specific reasons to not expose those useful functions to external projects?
I'm sure we'd consider it if there was a demand for them. As it is though, there's no guarantee those won't go away between releases, or change in incompatible ways, etc. Depending on what you're using them for, chances are that you should either be using the official Win32 APIs, or just be defining __WINESRC__. Perhaps you're doing something unusual enough that neither of those is an option, but in that case we'd be curious to learn more details.
On 18/11/2018 20:15, Henri Verbeet wrote:
On Sun, 18 Nov 2018 at 21:19, Andre Heider a.heider@gmail.com wrote:
Hm, are they private? They're installed, and using wine's debug channels work just fine. Looking at the file, there're specific macros for !__WINESRC__ too, e.g. WINE_FIXME().
I think that's largely historic, we didn't use to define __WINESRC__ for tests and programs.
Oh okay, gotcha.
Apart from the debug channels, we use these too: toupperW() (unicode.h) wine_dlopen() (library.h), and I guess a few more.
Again, what are you doing exactly that you need those?
Are the specific reasons to not expose those useful functions to external projects?
I'm sure we'd consider it if there was a demand for them. As it is though, there's no guarantee those won't go away between releases, or change in incompatible ways, etc. Depending on what you're using them for, chances are that you should either be using the official Win32 APIs, or just be defining __WINESRC__. Perhaps you're doing something unusual enough that neither of those is an option, but in that case we'd be curious to learn more details.
The result hopefully won't be unusual ;) This is about Gallium Nine. As you might know, it's currently distributed as patches on top on wine. I extracted the relevant code pieces into its own repository to make it a standalone project, independent of wine - but built as a winelib project.
That's why there're various uses of wine specific headers and functions. But you made me dig up the reason for using those (it's not my code base) - and I don't see one, heh. I could replace all the minor stuff with either win32 or libc alternatives. The only thing left now is the debug channel stuff.
It would be nice if I could just use that too, but it shouldn't be too much work to use something different. Maybe just plain old OutputDebugString()?
Anyway, if those headers are considered wine internal this patch can be dropped, as well as the other one "winegcc: add -I for the prefix's include dir".
If anyone cares: https://github.com/dhewg/nine Still a WIP, but works for me so far.
Thanks, Andre
On Mon, 19 Nov 2018 at 00:12, Andre Heider a.heider@gmail.com wrote:
Apart from the debug channels, we use these too: toupperW() (unicode.h) wine_dlopen() (library.h), and I guess a few more.
Again, what are you doing exactly that you need those?
Are the specific reasons to not expose those useful functions to external projects?
I'm sure we'd consider it if there was a demand for them. As it is though, there's no guarantee those won't go away between releases, or change in incompatible ways, etc. Depending on what you're using them for, chances are that you should either be using the official Win32 APIs, or just be defining __WINESRC__. Perhaps you're doing something unusual enough that neither of those is an option, but in that case we'd be curious to learn more details.
The result hopefully won't be unusual ;) This is about Gallium Nine. As you might know, it's currently distributed as patches on top on wine. I extracted the relevant code pieces into its own repository to make it a standalone project, independent of wine - but built as a winelib project.
That's why there're various uses of wine specific headers and functions. But you made me dig up the reason for using those (it's not my code base) - and I don't see one, heh. I could replace all the minor stuff with either win32 or libc alternatives. The only thing left now is the debug channel stuff.
It would be nice if I could just use that too, but it shouldn't be too much work to use something different. Maybe just plain old OutputDebugString()?
It would probably make most sense to use the Mesa/Nine debug functions, although for something like Nine, I don't think simply defining __WINESRC__ would be all that bad. I think things like using ExtEscape() to get at winex11 internals are more problematic. (I suspect that could be avoided, but historically I don't think the Nine developers have been very excited to discuss that particular aspect; perhaps that has changed.)
On 18/11/2018 22:32, Henri Verbeet wrote:
On Mon, 19 Nov 2018 at 00:12, Andre Heider a.heider@gmail.com wrote:
Apart from the debug channels, we use these too: toupperW() (unicode.h) wine_dlopen() (library.h), and I guess a few more.
Again, what are you doing exactly that you need those?
Are the specific reasons to not expose those useful functions to external projects?
I'm sure we'd consider it if there was a demand for them. As it is though, there's no guarantee those won't go away between releases, or change in incompatible ways, etc. Depending on what you're using them for, chances are that you should either be using the official Win32 APIs, or just be defining __WINESRC__. Perhaps you're doing something unusual enough that neither of those is an option, but in that case we'd be curious to learn more details.
The result hopefully won't be unusual ;) This is about Gallium Nine. As you might know, it's currently distributed as patches on top on wine. I extracted the relevant code pieces into its own repository to make it a standalone project, independent of wine - but built as a winelib project.
That's why there're various uses of wine specific headers and functions. But you made me dig up the reason for using those (it's not my code base) - and I don't see one, heh. I could replace all the minor stuff with either win32 or libc alternatives. The only thing left now is the debug channel stuff.
It would be nice if I could just use that too, but it shouldn't be too much work to use something different. Maybe just plain old OutputDebugString()?
It would probably make most sense to use the Mesa/Nine debug functions, although for something like Nine, I don't think simply defining __WINESRC__ would be all that bad. I think things like using ExtEscape() to get at winex11 internals are more problematic. (I suspect that could be avoided, but historically I don't think the Nine developers have been very excited to discuss that particular aspect; perhaps that has changed.)
I wasn't aware of that ExtEscape() issue, I'm just an independent guy that started to poke at nine recently. But I do care about clean code ;), Was that issue discussed in the past? Any suggestions to get rid of this hack?
On 18/11/2018 22:32, Henri Verbeet wrote:
On Mon, 19 Nov 2018 at 00:12, Andre Heider a.heider@gmail.com wrote:
Apart from the debug channels, we use these too: toupperW() (unicode.h) wine_dlopen() (library.h), and I guess a few more.
Again, what are you doing exactly that you need those?
Are the specific reasons to not expose those useful functions to external projects?
I'm sure we'd consider it if there was a demand for them. As it is though, there's no guarantee those won't go away between releases, or change in incompatible ways, etc. Depending on what you're using them for, chances are that you should either be using the official Win32 APIs, or just be defining __WINESRC__. Perhaps you're doing something unusual enough that neither of those is an option, but in that case we'd be curious to learn more details.
The result hopefully won't be unusual ;) This is about Gallium Nine. As you might know, it's currently distributed as patches on top on wine. I extracted the relevant code pieces into its own repository to make it a standalone project, independent of wine - but built as a winelib project.
That's why there're various uses of wine specific headers and functions. But you made me dig up the reason for using those (it's not my code base) - and I don't see one, heh. I could replace all the minor stuff with either win32 or libc alternatives. The only thing left now is the debug channel stuff.
It would be nice if I could just use that too, but it shouldn't be too much work to use something different. Maybe just plain old OutputDebugString()?
It would probably make most sense to use the Mesa/Nine debug functions, although for something like Nine, I don't think simply defining __WINESRC__ would be all that bad. I think things like using ExtEscape() to get at winex11 internals are more problematic. (I suspect that could be avoided, but historically I don't think the Nine developers have been very excited to discuss that particular aspect; perhaps that has changed.)
Hi,
Rest assured, we don't use ExtEscape to get winex11's dc_rect (which required specific patches indeed) since sometime around "7 Jan 2017" (date of the patch I can find in the log, but we may have had earlier patches).
We do still use it of course to get the X drawable because we need to present to the screen somehow, and it would be quite inefficient to trigger a copy via opengl for that, while we have support for the X Present interface enabling fine vsync behaviour. I doubt you would be interested we merge our work to winex11, but I may be wrong ?
Fortunately getting the X drawable doesn't require to patch wine, which means we can add nine on top of any wine installation.
Yours,
Axel Davy
On Mon, 19 Nov 2018 at 22:57, Axel Davy davyaxel0@gmail.com wrote:
Rest assured, we don't use ExtEscape to get winex11's dc_rect (which required specific patches indeed) since sometime around "7 Jan 2017" (date of the patch I can find in the log, but we may have had earlier patches).
We do still use it of course to get the X drawable because we need to present to the screen somehow, and it would be quite inefficient to trigger a copy via opengl for that, while we have support for the X Present interface enabling fine vsync behaviour. I doubt you would be interested we merge our work to winex11, but I may be wrong ?
Not directly, but I think we'd consider exposing an interface that's conceptually similar to Present. (I.e., "replace the contents of this window with the contents of this native drawable"), at least to internal DLLs like d3d9. The d3d9 dll could then pass a callback to Nine using that internal function to actually get things to the screen. There would be some details to work out, but I think that's an approach that may be worth exploring.
Of course I'd also still prefer Nine to be used as a wined3d backend instead of as a replacement for d3d9, but that's a mostly orthogonal issue.
On 20/11/2018 20:05, Henri Verbeet wrote:
On Mon, 19 Nov 2018 at 22:57, Axel Davy davyaxel0@gmail.com wrote:
Rest assured, we don't use ExtEscape to get winex11's dc_rect (which required specific patches indeed) since sometime around "7 Jan 2017" (date of the patch I can find in the log, but we may have had earlier patches).
We do still use it of course to get the X drawable because we need to present to the screen somehow, and it would be quite inefficient to trigger a copy via opengl for that, while we have support for the X Present interface enabling fine vsync behaviour. I doubt you would be interested we merge our work to winex11, but I may be wrong ?
Not directly, but I think we'd consider exposing an interface that's conceptually similar to Present. (I.e., "replace the contents of this window with the contents of this native drawable"), at least to internal DLLs like d3d9. The d3d9 dll could then pass a callback to Nine using that internal function to actually get things to the screen. There would be some details to work out, but I think that's an approach that may be worth exploring.
Of course I'd also still prefer Nine to be used as a wined3d backend instead of as a replacement for d3d9, but that's a mostly orthogonal issue.
How low-level would you see that interface similar to present ?
Our Functions working around Present are the Present* functions here:
https://github.com/iXit/wine/blob/master/dlls/d3d9-nine/dri3.h
They are implemented here:
https://github.com/iXit/wine/blob/master/dlls/d3d9-nine/dri3.c
It is important for some nine feature to be able to use this API in a multithreaded way, which complicates the code (thus the mutexes). Thus I don't know how much we would be able to use a different interface made more generic.
One way is to have a low level api, basically almost a wrapper around xcb present calls (listen to the present events of this window, present this pixmap at this time, etc).
The problem is that it basically needs to be very close to xcb, and thus isn't generic.
Yours,
Axel Davy
On Tue, 20 Nov 2018 at 23:01, Axel Davy davyaxel0@gmail.com wrote:
On 20/11/2018 20:05, Henri Verbeet wrote:
Not directly, but I think we'd consider exposing an interface that's conceptually similar to Present. (I.e., "replace the contents of this window with the contents of this native drawable"), at least to internal DLLs like d3d9. The d3d9 dll could then pass a callback to Nine using that internal function to actually get things to the screen. There would be some details to work out, but I think that's an approach that may be worth exploring.
Of course I'd also still prefer Nine to be used as a wined3d backend instead of as a replacement for d3d9, but that's a mostly orthogonal issue.
How low-level would you see that interface similar to present ?
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);
On 23/11/2018 17:36, Henri Verbeet wrote:
On Tue, 20 Nov 2018 at 23:01, Axel Davy davyaxel0@gmail.com wrote:
On 20/11/2018 20:05, Henri Verbeet wrote:
Not directly, but I think we'd consider exposing an interface that's conceptually similar to Present. (I.e., "replace the contents of this window with the contents of this native drawable"), at least to internal DLLs like d3d9. The d3d9 dll could then pass a callback to Nine using that internal function to actually get things to the screen. There would be some details to work out, but I think that's an approach that may be worth exploring.
Of course I'd also still prefer Nine to be used as a wined3d backend instead of as a replacement for d3d9, but that's a mostly orthogonal issue.
How low-level would you see that interface similar to present ?
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).
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 ?
Axel
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:
On Fri, 23 Nov 2018 at 23:25, Axel Davy davyaxel0@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.
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@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
On Tue, 27 Nov 2018 at 20:31, Axel Davy davyaxel0@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.
On 27/11/2018 19:30, Henri Verbeet wrote:
On Tue, 27 Nov 2018 at 20:31, Axel Davy davyaxel0@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
Yes, that's what I meant. It's equivalent (it means the server is done with your buffer and won't use it ever again).
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.
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 ?
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.
Please note I have some experience in the area, as I also contributed to the egl wayland backend, the glx dri3 backend and wrote the first complete XWayland Present implementation,
which I hope will help get that generic API right (but I don't pretend to have the truth there).
(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).
In terms of other platforms, we have Android/ChromeOS, Wayland, and MacOS. Some of those could conceivably run Nine.
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.
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.
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.
Henri Verbeet hverbeet@gmail.com writes:
On Sun, 18 Nov 2018 at 20:56, Andre Heider a.heider@gmail.com wrote:
wine/debug.h is a public header, and ARRAY_SIZE() is not defined for external projects.
The change itself seems harmless enough, but the premise seems wrong. Headers in include/wine are private Wine headers; why do you need (or want) to include wine/debug.h?
A few of these headers are public, the idea being that they describe the libwine API, which can potentially be used outside of Wine.
It's not clear that this is particularly useful, and maybe we should stop exporting them. But as long as they are exported, the change would make sense.
-
Alexandre Julliard -
Andre Heider -
Axel Davy -
Henri Verbeet