https://bugs.winehq.org/show_bug.cgi?id=39440
Alexey Chernov 4ernov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |4ernov@gmail.com
--- Comment #19 from Alexey Chernov 4ernov@gmail.com --- Ironically, I've been trying do roughly the same functionality, as @phant0m used to do with Airwave (which worths many thanks for quite matured, but apparently nowadays unmaintained product) and faced the same issue, but after digging a little deeper into the mechanics, Wine source code and XEmbed and WINAPI specifications I tend to think the Wine implementation of XEmbed management is OK for now, and the cause of the problem is just timing/sequence violations during the opening of the windows.
In short, here's what we're trying to do to make the VST plugin window content be built-in in the plugin window provided by the DAW:
1. Create "pseudo" parent window in Wine world to pass its handle as a parent window to VST routines (so that all the window content be embedded in something).
2. Get X11 window-id of this parent window and embed it to real X11 parent window (kindly passed to us by the DAW) to make it feel like the plugin visual content is embedded into plugin window opened by the DAW. So, there are 3 windows involved instead of two, as we typically can't "convert" real X11 parent window to Wine window to use it as parent there.
Since step 2 implies a sequence of actions which are generally not atomic and also sometimes asynchronous, different problems may arise, from the normal expected behaviour to the described artifacts appeared. I found the following sequence working stable for me (I'll reference my code on GitLab, have just made a separate branch there especially for this report to make code links consistent over time):
1. We create "pseudo" parent window in Wine (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/wine/edi...) and starting to receive Windows messages for it. Window creation seems to be synchronous.
2. We pass the handle of this window to VST plugin as a parent window, it starts to paint etc. (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/host.h#L... but that part is not so relevant).
3. Being subscribed to the "pseudo" parent window messages, we soon receive WM_PARENTNOTIFY message with WM_CREATE parameter (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/wine/edi...), which means the plugin has done its job, created the window. We pass this message together with the updated window size to our X11/non-Wine side (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/wine/edi...).
4. On our X11 side we first resize our real parent window to the reported size, then re-parent our "pseudo" parent window (by its X11 window id found by "__wine_x11_whole_window" on Wine side and kindly passed to us from there) to the real parent window and also embed the former to the latter (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/plugin... https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/editor... https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/editor...). Now it's apparently safe to map our "pseudo" parent window finally.
Carefully keeping this sequence in order is enough, to my experiments, to always have the window opened and painted stable and fine. So, my personal short conclusion is that this bug is safe to be closed on the Wine side, as I haven't found any misbehaviour, yet. Still, as I'm not an expert in this area and just has to be my knowledge refreshed after my experiments with it about a year ago, it probably might need additional research, if there's manpower/will for it.