https://bugs.winehq.org/show_bug.cgi?id=57833
--- Comment #5 from Andie andiejs@gmail.com --- Here's some more info from another helpful user: (link https://github.com/robbert-vdh/yabridge/issues/386#issuecomment-2654876975)
"Maybe link this issue in your bug report.
DxgiFactory::CreateSwapChainForComposition
is the problem but it's not a problem with wine. Wine has vkd3d for D3D12 (which has been forked to vkd3d-proton). This feature has been implemented already in vkd3d but the stack is not mainstream yet. The current native D3D implementation in wine tops out at D3D10, I think.
What most people used for earlier JUCE plugins and JUCE 8 plugins that have been written to fall back to older rendering methods is dxvk. dxvk is separate from the wine project and provides D3D8-11 with a focus on games. A dxvk developer has said they won't implement that feature.
So the problem we have is that the feature is not there in dxvk and won't be added and people use dxvk for plugins because it performs better than the native wine D3D implementation currently in many cases."
If this is correct and this is truly an issue separate from WINE I'm going to have to hunt down the dxvk people and bug them. Please let me know if you have a sense of who/where this would be. On the other hand if the native wine D3D were up to speed with JUCE 8, that would be good too of course.
I'm going to have to make sure I have a sensible wine prefix and find a good example for you; I'll try to post a simple test example and/or some logs tomorrow. Thanks again.