Rendering issues when embedding a Win32 window inside WPF

Question

Hello,

We have a pretty big WPF application, and the task in hand is to embed a Win32 window (with C++ (QT) content in it) onto one of the WPF pages. Since this is a classic Win32/WPF interoperation, the natural way of implementing this is to use a class derived from HwndHost, and doing the reparenting of the hosted child window in the overridden BuildWindowCore method.

In order to simplify and get the doubt that it could be related to the Win32 app out of the way, I just use Notepad.exe to embed (this reproduces equally).

What we are seeing is that after the hosted window is added to the Element Tree, the WPF controls next to it (buttons, sliders,..) stop behaving normally. I still get the mouse events, click events, but hover states are not working, the thumb of the slider doesn't move and a gif animation stops animating. This sounds to me as WPF's Rendering thread is having problems. Could it be blocked somehow? Or not playing nicely with Win32?

Dwayne Need writes this in his article about Airspace issues:

The splitting of user-interface processing and rendering across separate threads is unusual in Win32 applications, and doubtless the source of many subtle bugs. If integrating child windows into your WPF application is a primary concern, I strongly recommend disabling WPF hardware acceleration. By disabling hardware acceleration, WPF will render using GDI. This eliminates many issues because GDI can coordinate correctly even from multiple threads. If disabling hardware acceleration is not an option, we will review some mitigations that work around most of the rendering artifacts I know of. Unfortunately these mitigations are not always trivial.

Disabling hardware acceleration does make this problem go away, but it doesn't sound as a solution as this will affect all WPF-based apps on the machine.

What throws me off even more (and make me doubt my rendering thread theory) is the following 2 facts:

1. If ALL the controls on this page have any kind of Style on them (even an empty Style (!!!)), this doesn't reproduce. As soon I take the style off of one of them, it starts happening again.
2. Adding these controls to a GroupBox makes this reproduce (regardless of Style being present or not).

I'm not sure if this is just a red herring, or that Style and GroupBox does have a strange contribution to this issue.