You’re asking for the impossible. WINE doesn’t provide the needed functionality, and forcing everybody else to an older version so your three WINE users can use your products is unreasonable.
We had one customer who can’t use NEXUS5 because he uses WINE.
I didn’t say that we remove any functionality. I found it might be worth considering a solution to downgrade some functionality to an older Direct2D version for compatibility. That’s all.
That’s true, WINE and also LINUX support is nothing that pays out. I’m aware of that.
Lol, I’ve never heard anyone say this …
Hey guys, I’m a user who has thousands of dollars worth of plugins that are becoming incompatible with my system and I’m unable to do my work. It’s pretty dire over here.
Thanks for your advocacy, @kunz. We wine users bought your products same as everyone else, and despite our comparatively small numbers, there are reasons for running plugins on linux systems, and linux is something that should be supported if at all possible.
I don’t see why JUCE can’t make sure there’s compatibility with WINE. From what I’m seeing here it shouldn’t be too technically difficult on their end. I just want to boost this thread and say I’m really counting on this happening in some way.
If anyone has any solutions for me or can suggest any way I can help make this happen, I’m all ears.
@kunz @pflugshaupt any chance you can advise over here at winehq? trying to see what would be needed on their side to support JUCE 8.
As previously stated what is missing is D2D feature level 1.3. Wine only supports level 1.2.
As far as I am aware, the 1.3 features that JUCE8 needs are storing paths in GPU memory and the new flip-type swap-chain mode for windowed apps, but of course only full 1.3 feature level support would ensure long-term compatibility.
Thank you! Re-posting/linking that over on the WINE side. Hope that’s something they’re able to do; will probably be useful for many applications.
Maybe if devs would build native plugins people wouldn’t use “crutches” (aka: alternative ways to run software) on their machines.
But I agree that that statement is completely useless to the discussion.
Imo JUCE is not obliged to make itself “compatible with wine” when it is in fact already “compatible with Linux” and a “crutch” like wine shouldn’t be needed in the first place.
The fact that wine works most of the time is pretty cool, but users should not expect it to be the solution for their paid plugins to work on their machines. (I personally only use it for free plugins that are not native and I pay developers that make an effort to support my OS of choice)
@drmr-2 There is an extremely rare case. Although I do provide Linux native plugins, one user told me that he couldn’t run my plugin with WINE. And because he also runs Reaper in WINE, he is not able to load Linux native plugins (I haven’t verified it though). Till now I have only received one bug report on this.
Looks like disabling D2D when under wine is the simple solution that don’t require much thing. It’s not like it’s going to hurt the D2D aspect and we will always need a software renderer so it’s not a burden to have this.
There were some posts that were previously a part of this thread that I’ve since removed, these were either off topic or below our normal high standards of conduct. I will contact all individuals privately.
It’s not that simple. The vblank mechanism, that is always used regardless of the renderer, requires functionality that Wine doesn’t provide.
If it was such a simple change, I’m sure the JUCE team would have done it by now.
I do think it’s disappointing that WINE doesn’t support Direct2D 1.3 given that it’s almost 10 years old. We’ll evaluate the cost of adding something that helps WINE support, but it may be surprisingly involved. Relying upon a dependency that has been a core part of Windows for a decade is not unreasonable, and it makes framework source less complex.
I’m sorry, but this is just wrong information. As I stated previously, the vblank mechanism works on Wine. Users just need to install the dxgi.dll using winetricks. The only thing that currently cannot be emulated is the rendering itself.
I only had to change a few lines of code (linked above) to detect Wine and make the renderer fall back to software while it is using the unpatched Vblank mechanism.
Could you clarify this –
Hypothetically if the issue were to be fixed on the WINE side of things so that JUCE wouldn’t have to patch around it:
The issue that needs fixing is that CreateSwapChainForComposition is not implemented (in dxgi.dll). Complicating things is that there are two implementations of dxgi, the native WINE version and the DXVK version.
Supposing CreateSwapChainForComposition were implemented in the native WINE version, would this make JUCE work? Or is there some other reason that the DXVK version of dxgi.dll is needed / something else that would have to be fixed in the WINE version (something about Vblank?)
Sorry, I know you clarified above “As far as I am aware, the 1.3 features that JUCE8 needs are storing paths in GPU memory and the new flip-type swap-chain mode for windowed apps, but of course only full 1.3 feature level support would ensure long-term compatibility.” but that has to do with D2D wheras it seems that there’s a DXGI issue which is not the same thing. Forgive me this stuff is a little out of my wheelhouse, I’m trying to understand how it all fits together.
Actually I’m thinking that DirectComposition support should be removed.
DirectComposition was originally used to implement transparent windows, but that’s no longer the case. I think we can remove it entirely. That might solve the problem.
Matt
Give it a try with my unofficial branch.
Matt
@matt, I tried to run the DemoRunner on wine-staging/Ubuntu 24.04.
With your changes, the .exe actually loads and runs for me without any changes.
However, it is far from working correctly. Fonts are not rendered at all and I get low fps on the animation after launch and broken antialiasing. So this is clearly not a usable solution to the Juce8/wine problem.
Meanwhile the .exe I built using my patches/changes that make JUCE8 fall back to the software renderer if wine is detected work just fine.
I believe as long as the JUCE renderer is developed to target Windows 10 Direct2D (feature level 1.3) while wine only supports Windows 7 Direct2D (feature level 1.2), the JUCE d2d renderer will never work right on wine and any change could break it again even if it was working. Therefore falling back IMHO is the only reasonable solution.
OK, thanks for giving it a try.
Seems like you could just set the window to use the software renderer without any JUCE changes. What happens if you do that?
Matt
