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?