Juce8 Direct2D WINE/yabridge

[pflugshaupt]

I received a report that a plugin no longer displays any graphics on a Linux system using yabridge/WINE. I recently updated the plugin to JUCE8.0.3

yabridge is a tool to load Windows audio plugins on Linux systems using the WINE emulation layer.

GitHub - robbert-vdh/yabridge: A modern and transparent way to use Windows VST2,...

Unfortunately, I’m not very familiar with Linux/WINE. Has anyone managed to run JUCE8 Windows binaries on WINE and got the rendering to work?
I guess the problem is that the Direct2D version WINE emulates is too old for the JUCE8 d2d renderer. Is there any hope WINE will update to the Windows 10 level?

It would be very desirable if JUCE8 could automatically fall back to the software renderer on systems that don’t have the required d2d version…

[matt]

Wine appears to support Direct2D. What version of Wine are you using?

Installing winetricks might help.

Matt

[pflugshaupt]

Thank you for the reply. I just got this reported by a customer and am not sure what to tell him. I currently have no machine running Linux. The customer appears to run the latest Wine release as he told me he’s hoping it’ll improve to fix the black window rendering in the future.

Are you saying it is currently possible to get graphics running on the latest Wine with a Juce8 Windows binary? That’s all I’d like to find out.

[pflugshaupt]

It appears Wine supports Direct2d feature level 1.2, but Juce8 requires Direct2D feature level 1.3.

[pflugshaupt]

I found that falling back to the software renderer as described in the other thread by matt enables juce8 binaries to run and display under wine.

Direct2D Causes Considerable Performance Drop

Question - based on your previous posts, you obviously have have a lot of experience with OpenGL & Vulkan. For DX11 & DX12, you have to handle unexpected adapter removal. I’ve been playing with Metal and there doesn’t seem to be an equivalent. How do you handle that in OpenGL and Vulkan? Say, for instance, you unplug an external GPU, or the device restarts. Matt

It’s possible to detect whether the code is running under wine using:

bool _runningUnderWine() {
	auto hntdll = GetModuleHandleA("ntdll.dll");
	if (!hntdll) return false;

	auto pwine_get_version = GetProcAddress(hntdll, "wine_get_version");
	return (pwine_get_version != nullptr);
}

That way d2d can be disabled only when running under Wine.

[drmr-2]

Why not give a hand at building native Linux plugins instead?

If you are running Windows (10/11) it already comes with a version of Linux installed (called WSL).

[pflugshaupt]

Building native Linux plugins would of course be ideal for Linux.

But in my case, upgrading to Juce8 has led to black GUIs for Wine/Yabridge users that have been using my windows builds just fine before and I’d like to fix that regardless of providing Linux builds or not.

[kunz]

I also received a report about this. We have Linux versions, but the Linux audio ecosystem is still limited and some use Wine as an alternative. This used to work perfectly with JUCE 7.

[eyalamir]

We also received these reports (and also don’t want to distribute native Linux builds currently).

My guess was that it’s related to the Direct2d dll, is that possible?

[kunz]

@pflugshaupt

It appears Wine supports Direct2d feature level 1.2, but Juce8 requires Direct2D feature level 1.3.

Is there something WINE users can do about this on their side? I wasn’t able to find useful information about this. In my case, the user runs FL with WINE on Linux and he can’t use our native Linux builds for that.

[pflugshaupt]

No, but I got my Juce 8 builds to work once I added wine detection which then leads to a fallback to the software renderer.

Without any patches to Juce 8 it is impossible and there is very little chance wine will support Direct2D feature level 1.3 in the near future - it appears nobody is working on that.

Additionally, it is necessary to install dxvk using winetricks. This was not the case with Juce 6. Dxvk is now required to satisfy the new .dll dependencies and (I guess) to support the newer refresh sync.

[kunz]

@pflugshaupt

Without any patches to Juce 8 it is impossible and there is very little chance wine will support Direct2D feature level 1.3 in the near future - it appears nobody is working on that.

Additionally, it is necessary to install dxvk using winetricks. This was not the case with Juce 6. Dxvk is now required to satisfy the new .dll dependencies and (I guess) to support the newer refresh sync.

Thanks for the information. Too bad.

Dear JUCE team, is there something you can do about this? Probably DirectX 1.2 features already work to draw some shapes and gradients or include the workaround from above?

[dev1am]

We’ve received similar reports: since JUCE 8, WINE compatibility appears to be broken (everything worked fine with JUCE 7). It would be great if the JUCE team could release a patch for WINE compatibility, as suggested by @pflugshaupt

[djb-2]

+1 we also getting requests to fix WINE compatibility after moving to JUCE 8.

There is another thread where people are asking a feature to disable Direct2D rendering (because of performance issues mostly); I wonder if this could be another argument for the JUCE team to provide a mode where we can disable Direct2D and have WINE compatibility at the same time?

[kunz]

+1 for the WINE Patch by @pflugshaupt

Received another request. We need backward compatibility.

[kunz]

Bump… I fear to update all our plugins because of this. Many Linux users out there prefer WINE over native Linux software and having access to all Windows audio software.

Maybe it’s possible to have a workaround inside the DirectX code? This is the error message a user sent me:

DxgiFactory::CreateSwapChainForComposition: Not implemented

Probably it’s only that call that fails and there is a simple workaround!? Disabling Direct2D for the WINE environment would also be a solution for me. But this has to be added to the Juce framework. It’s too risky for me to patch code in areas where the code changes a lot and that’s hard to test.

[pflugshaupt]

It is easy to add a workaround yourself until the JUCE team adds it (potentially never ).

Just disable d2d rendering as Matt has explained in the other thread. It’s just two spots in the juice_windows code.

This is how I implemented it on my fork:

add wine detection method.

detect wine and fall back to software rendering in that case.

The AP_DISABLE_D2D macro is my personal way to disable d2d under windows as well.

People still need dxgi from winetricks for the vblank code (which works fine under wine). I tell them to do winetricks dxvk which contains dxgi.

[kunz]

Okay, thanks. I thought it was more code. Didn’t know that there was already a macro to disable Direct2D.

Anyway, I’m unsure if I want to take on the burden of patching JUCE, especially if there is no hope that this will be added in the future. The time you lose when updating because of things like that, sums up.

Still have some hope for a solution for this from the JUCE team. Making the Direct2D code compatible with WINE would be the best solution.
This is a problem all plugin companies will have when switching to JUCE 8. It makes no sense, that we all have to patch the JUCE code. WINE users also bought our products and they can’t use them anymore when we update.

[pflugshaupt]

That is my own macro. I find a small change like this not to be a burden as juce changes can just be merged in on GitHub. A few lines of code have a low chance of being affected.

[kunz]

@pflugshaupt

I find a small change like this not to be a burden as juce changes can just be merged in on GitHub.

It’s one thing more, you need to keep an eye on for a whole product lifetime.