and now the JUCE team has to support the software renderer forever. Which is not cheap.
Perhaps someone should bring WINE up to date instead?
No. The JUCE team has to support the software renderer anyway. It is used for native Linux builds and for rendering to software bitmaps.
I tried the PIP on my Ubuntu machine, but it showed a black window (before clicking the black-on-black button) and it did crash after a few seconds - even without ever switching to the d2d renderer.
I think the d2d renderer needs to be fully disabled, so there is no way a context is ever created, in order to successfully run under Wine.
Without a commitment of the JUCE team to support d2d rendering under Wine (which seems very unlikely), I think disabling d2d and fully reverting to the Software Renderer is the only sustainable option - it also matches native Linux builds in rendering performance, which makes it seem reasonable.
Hello all!
I’ve been looking into this and trying to determine what might be involved in trying to make JUCE applications/plugins at least usable in Wine.
@pflugshaupt What version of Wine are you running? Just to confirm are you able to get DemoRunner working correctly with a software fallback? I’ve installed the latest DXVK and installed all available fonts in winetricks. I’m able to get a simple application to work but DemoRunner does not.
I am able to run DemoRunner.exe with my patches. I didn’t need to install fonts for that. If fonts are missing then I guess the d2d renderer is not fully disabled as I cannot get any font to render under wine using patched versions of the d2d renderer.
I use wine 10 staging on Linux Mint 22 currently. All I needed to do was install wine staging from winehq, install winetricks and install dxvk using winetricks.
However… yabridge currently is not working correctly with wine 10. GUIs have a mouse offset due to changes that happened in Wine 9.2.2. If you want to test yabridge, you need Wine staging 9.2.1.
Update: I’m sorry - I was wrong. DemoRunner won’t work anymore with the patches I listed earlier. I have no idea why. I tried building on j8 develop with my patches and now the exe can’t even be launched regardless of wine version. My older .exe files still load but I honestly have spent too much time on this already so I’ll give up for now - my plugin vst3 builds do work using yabridge/wine9.21 and that’s all I need. Not sure what is different, the only thing I know for sure is that I am using embedded fonts - maybe loading fonts from disk is broken.
Update2: Actually the freshly build DemoRunner does work - it just takes minutes to load and can’t render any text.
That’s where we got to. Even with the fonts installed via winetricks there’s a lot of other things going wrong and we’ve tried a few different ways of falling back to the software renderer without any success.
Ultimately, making this work looks like a big time investment and there are many other different areas of JUCE where that investment would be much more valuable, so we’re not going to investigate any further.
So I couldn’t let it rest. Looking at font loading I found that JUCE already contains code to detect whether it is running under Wine, namely juce_isRunningInWine() in juce_Threads_windows.cpp Line 303:
bool juce_isRunningInWine()
{
HMODULE ntdll = GetModuleHandleA ("ntdll");
return ntdll != nullptr && GetProcAddress (ntdll, "wine_get_version") != nullptr;
}
Now where is this used? Turns out, it is used during font loading.
In juce_DirectWriteTypeface_windows.cpp there is:
struct DefaultFontNames
{
DefaultFontNames()
{
if (juce_isRunningInWine())
{
// If we're running in Wine, then use fonts that might be available on Linux.
defaultSans = "Bitstream Vera Sans";
defaultSerif = "Bitstream Vera Serif";
defaultFixed = "Bitstream Vera Sans Mono";
}
else
{
defaultSans = "Verdana";
defaultSerif = "Times New Roman";
defaultFixed = "Lucida Console";
defaultFallback = "Tahoma"; // (contains plenty of unicode characters)
}
}
String defaultSans, defaultSerif, defaultFixed, defaultFallback;
};
This is problematic for multiple reasons and should probably be removed. The Bitstream Vera fonts are outdated and are not included in modern linux distros. But much worse - there is no fallback defined if Juce is running under Wine and that’s almost sabotage 
.
If I download/install old .ttf files of Bitstream Vera and Bitstream Vera mono, text gets rendered and launching is much faster as well. This is using the software renderer:
Unfortunately, the demo menu is still broken… feels like a different missing font. Maybe I’ll investigate further later.
@t0m, if you are planning to not support Wine in J8, could you remove the wine detection and the outdated fonts without fallback that only complicate things?
This whole thing explains why I got it to work for my plugins… I only use embedded fonts.
…and now I found the reason why the Demo menu was not working. It’s because DemoRunner searches through the enclosing JUCE source folders to find out what demos exist. And I copied the .exe only… D’oh.
Copying the full “examples” folder structure over to Linux and forcing the software renderer I finally get a mostly working DemoRunner.
Then it is not possible to make JUCE 8 work on Wine even when enabling the software renderer mode when using embedded fonts?
For me using embedded fonts + the software renderer does work - it’s just the default fonts that don’t work due to that strange WINE override in the JUCE code.
Hi! I’m also struggling with black gui in JUCE-based plugins under Wine. If I understood correctly, falling back to the software renderer when detected Wine should solve majority of issues with plugins transitioning to JUCE8.
If this is the case, is this change - something on the roadmap in JUCE? When could we expect the change to be released?
Wrong way to put it, tho. You missed at least one customer, exactly me, just because of that.
I know I’m late to the party, sorry for the zombie topic.
Fabrizio
In the meantime, some of our customers also contacted us because of the issue. One of them said that they fixed it by running this script on the binary which obviously replaces some offending function calls in the binary, which is a slightly impressive solution 
Anyway the existence of this patch lets it seem like an easy fix to the customer. Given that this topic comes up constantly for our support over the last months, did the JUCE team re-evaluate their decision to not look into an official fix for this @t0m? We might end up fixing it ourselves but would strongly prefer an official solution from the JUCE side so we are hesitant to invest an unpredictable amount of time into this topic if there are chances for an official fix.
As @Toddler-Boy stated one of his users can’t use Nexus on linux, and maybe it’s only me but on wine also on proton from valve we have support for Direct3D rendering for the versions 9, 10, 11 and 12 and we have DXVK to run games on linux. I already have some VSTs which actually can work with that DXVK translation layer like shaperbox. It’s not the same industry but games are running on linux just because of that. If the Juce framework could be using just Direct3D rendering for sure the plugins will be running on linux and this way is supported completely like running Triple AAA games is. Also they guys from bitwig studio are using vulkan to render his daw from the GPU and that allows the daw to not be so resource hog rendering stuff.
Wouldn’t that be enough reason to just create native builds?
Not sure if this is the right place to discuss this in general. But to make it short, yes I as a developer would be more than happy to ship native Linux builds, however I’m also not the one to decided that. I see the amount of time that our QA people put into manually testing our rather complex plugins on the currently supported platforms in a bunch of major hosts which is significant – and even with that amount of testing, some issues slip through the net from time to time because you can’t test everything.
If we released Linux versions we would probably want to test them to the same quality standards as we do with macOS and Windows builds and honestly the increase in sales will probably not outweigh the increase in QA work hours – guess that’s the sad main reason why we and many other companies do not “just create native builds”.
If there is more need to discuss this aspect, I’d propose to start a new thread about that and keep this one focused on the technical issues around running JUCE based plugins on wine.
I’m afraid our position hasn’t changed.
We don’t want to include partial support for Wine, where JUCE will work in some situations but not others, and getting beyond partial support looks like it is going to be a lot of work.
Native plug-ins are not a solution for WINE users. We have native linux plug-ins, but still get requests for this. Many audio software is not available for Linux Native. WINE makes it possible to compensate the lack of software. This worked pretty well in the past.