Consider Implementing dxgi: Implement IDXGIOutput::WaitForVBlank()

[linux-leo]

This is my personal blocker trying to run the Truepianos 2.0 aarch64 windows binary under arm64 linux. Here's a pr made on the main repo: https://gitlab.winehq.org/wine/wine/-/merge_requests/10246

And the corresponding wine bug regarding JUCE: https://bugs.winehq.org/show_bug.cgi?id=56799.

I have not tested your branch yet however. If any of your changes bypass the need for this function lmk.

Edit: Off Topic, but a Fedora COPR would be amazing and simplify testing this branch.

[giang17]

Thanks for the report and the pointers to MR !10246 and bug 56799 — both very relevant.

Short answer: on this fork (d2d1-dcomp-11.0) the JUCE refresh freeze from bug 56799 does not occur, including with the exact plugin from that bug report. I've confirmed MJUCjr.vst3 runs and refreshes fine, alongside a number of other JUCE 8 plugins/standalones (Trinity, Pianoteq 9, EZ Keys 2, …) that all hit the DXGI composition-swapchain / Direct2D path.

Why it works here (two pieces, both present in this fork, both absent in vanilla):

1. The composition-swapchain / DComp path (CreateSwapChainForComposition) that JUCE 8's Direct2D renderer needs is implemented here — so the renderer takes the path it expects instead of freezing.
2. IDXGIOutput::WaitForVBlank is a semi-stub returning S_OK with a ~16 ms sleep instead of E_NOTIMPL (effectively the same as Nikolay's patch in attachment 76606 of bug 56799), so the wait doesn't stall the refresh loop.

Honest caveats:

• It is still a stub, not real vblank synchronization. Upstream reviewers have pushed back on the sleep direction (Zeb Figura in the bug, the reviewer of !10246 on busy-waiting), so a proper non-busy-wait implementation is still the open upstream goal. For audio-plugin GUIs the stub is sufficient in practice (no game-style frame-timing dependency), which is also why the whole JUCE-8 matrix here behaves correctly.
• My testing is x86-64 only. Your Truepianos 2.0 case is aarch64/arm64 — the dxgi/DComp logic is architecture-independent, so an arm64 build should behave the same, but I can't verify arm64 from my side.

For Fedora, there's actually already a COPR maintained by Patrick Laimbock that builds this stack (currently tracking 11.13), which is probably the easiest way for you to test:

• Spec files: https://codeberg.org/MusicProduction/
• Builds: https://copr.fedorainfracloud.org/coprs/patrickl/wine-staging-dev

Worth checking whether that COPR is built for aarch64 as well, or asking for that arch — that would give you a ready-made arm64 build to point Truepianos 2.0 at. Would love to hear how it behaves.

[giang17]

Quick update: I picked up Truepianos 2.0, and can confirm v2.0.122 runs flawlessly on this fork (x86-64).

The binary is built with JUCE 8 and its native Direct2D renderer + DXGI composition-swapchain (Direct2DGraphicsContext, Direct2DHwndContext::SwapchainDelegate, DxgiAdapter, ID2D1DeviceContext1 are all present in the exe) — i.e. exactly the render path that triggers the bug-56799 refresh freeze on vanilla. So this is your exact plugin and version on the exact path it needs, just on x86-64 rather than arm64. It refreshes and renders correctly, which is the strongest confirmation yet that the arm64 build should behave the same once it's built/tested.

(On a personal note: I hadn't tried Truepianos before — the sound is genuinely excellent and a very convincing alternative to Pianoteq 9, so well worth getting it running under arm64-Linux. Looking forward to hearing how it goes.)

[plaimbock]

@linux-leo I don't have aarch64 enabled. I will activate it when I find some time this week. If the d2d1-dcomp-11.14 branch is available I will update the copr to 11.14.

[giang17]

@plaimbock The d2d1-dcomp-11.14 branch is pushed and available now:
https://github.com/giang17/wine/tree/d2d1-dcomp-11.14 — based on the wine-11.14 tag, commit bda68077a7d.

Two fixes landed today and are included:

• server: Send a cursor update when the pointer becomes visible again — a wineserver fix, not DComp-specific. ShowCursor(TRUE) sent no cursor update when the effective cursor stayed NULL, so after dragging a slider the pointer stayed invisible until the mouse left the window and came back. This affects any application that hides the pointer while dragging, so it may be worth having regardless of the D2D1/DComp stack.
• dcomp: Skip the vacated-area restore while the whole toplevel moves — fixes white flicker while moving a plugin editor window.

[plaimbock]

@giang17 thanks!