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