http://bugs.winehq.org/show_bug.cgi?id=58552
--- Comment #40 from Stian Low wineryyyyy@gmail.com --- (In reply to Patrick from comment #39)
Based on my testing the offset is still there just not always. So I would not call it fixed. See https://github.com/robbert-vdh/yabridge/issues/409#issuecomment-3207331228
Agreed this issue should be left open for now.
I reproduced your Bitwig test results which required moving the VST window to fix the GUI offset which breaks again once the window is hidden and redispayed.
So far Carla/yabridge offset issues are resolved by yabridge new-wine10-embedding branch.
LMMS exhibits an opposite problem to Bitwig with Vestige VST windows initially opening correctly without GUI offset which breaks as soon as the window is moved from the original position and fixed when moved back to the original position.
What's unclear is whether the apps themselves contain incompatible code or if the fault lies within Wine itself.
For instance, if Carla contains windowing wrapper code that is compatible with yabridge new-wine10-embedding branch but Bitwig does not it begs the question, where does the fault lie? Is it wine itself or the apps that may contain incompatible wrapping the code.
I leaned toward assuming the remaining problems are related to the app wrappers because yabridge was modded for compatibility but that may be too premature an assumption.
I will take a look at how Carla is wrapping VST windows to compare against other apps with available source that still exhibit GUI offset issues to clarify where the fault lies. Bitwig source doesn't seem available to compare against Carla's way of handling windows.
When dealing with Windows apps, Wine hacks are valid to get apps working since they are considered black boxes with source that is not easily modded.
However when dealing with Linux apps interacting with Wine, they may be treated differently preferring mods to the original source as fixes vs hacks and workarounds for Windows apps? Meaning if Linux code is considered at fault and incompatible with latest versions of Wine then it should be modded for compatibility vs Wine adding hacks to work around whatever incompatibilities.
Backwards compatibility should be prioritized but it may have been considered less feasible against so many major changes made to the windowing system since 9.22.
Maybe clarifying how these various apps are wrapping the windowing functionality will lead to some Wine patches that support backwards compatibility without each app needing to be modded and rebuilt for compatibility.