[Bug 39440] embedded (XEMBED) windows are blank

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=39440

Alexey Chernov <4ernov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |4ernov at gmail.com

--- Comment #19 from Alexey Chernov <4ernov at 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/editor_forwarding.h#L80)
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#L203
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/editor_forwarding.h#L250),
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/editor_forwarding.h#L234).

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.h#L218
https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/editor_forwarding.h#L71
https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/editor_forwarding.h#L86).
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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.