"Stay on top" bug when project contains VST effects

[Sauerstoffdioxid]

When I load a project which contains at least one VST effect, the "stay on top" function is broken.

Steps to reproduce

1. open LMMS
2. On the default project, add a VST effect to the master channel
3. Save the project
4. Load the project
5. Enable "Stay on top" on for instance the Controller Rack
6. Open e. g. the Piano Roll

Expected

Everything works fine, i. e. windows interact as normal except the Controller Rack staying on top.

Actual

If you move the Piano Roll you should notice graphical glitches when it is on top of other windows. Trying to interact with it while it is on top of another window will result in interacting with the window below.

---

When you disable "stay on top", everything will work as expected again.

May be related to #4110, as this will only happen with VST effects. This bug persists after loading another project/creating a new project, just like the strange boxes from #4110.

[musikBear]

Yes i have also seen the 'echoed' graphic error, but also without enabling 'stay on top'. I think the glitch is more depending on what window is beneath it, and how that graphic scales ( -Also reported earlier, when qt5(?) was chosen

[DomClark]

Reproduced on 1.2.0-RC5, Windows 10 x64. Occurs for both VST effects and instruments using both Win32 and Qt embeddings.

Some speculation: prior to embedding a VST, all the subwindows in LMMS are non-native ones entirely managed by Qt, but upon embedding, these all become distinct native windows, so this might be a Qt bug.

Edit: Cannot reproduce on 1.1.3.

[DomClark]

This appears to be a Qt bug, I've managed to recreate it outside of LMMS. Here's a simple test case in Python: https://gist.github.com/DomClark/97b7e54b366b57bdfc5fed29c888c4ea

[zonkmachine]

I failed to find an upstream issue for this but it's quite a task to search the qt bug tracker.
Search: QMdiSubWindow

[musikBear]

I failed to find an up-stream issue for this

@zonkmachine
I think its #4110

[zonkmachine]

I failed to find an up-stream issue for this

@zonkmachine
I think its #4110

With upstream meaning a project that lmms depends upon (Qt, ZynAddSubFX, SDL, etc.). In this case Qt. The fix for #4110 is made by the same developer who suggests this is a bug with Qt (Three posts up).

[Sauerstoffdioxid]

I don't really understand much of this, but https://bugreports.qt.io/browse/QTBUG-63787 sounds related, which seems to be fixed in Qt 5.9.2 (If I searched on here correctly, LMMS is using 5.9 Found a commit saying LMMS is using 5.9.2)

[DomClark]

My version of RC5 (x64 Windows) is using Qt 5.4.2, but I can still reproduce this with the latest stable Qt (5.10.1), so it doesn't seem to be fixed yet.

[DomClark]

Qt issue opened at https://bugreports.qt.io/browse/QTBUG-69343.

[tresf]

@DomClark possibly related: https://bugreports.qt.io/browse/QTBUG-30181.

As a temporary workaround, in #4558 we disabled the call to parent-window()->winId() and MacOS stopped having this issue.

[tresf]

Quoting @DomClark from #4875

I can't reproduce this following the steps [from #4875]. However, if I first load a VST with embedding enabled, then I can reproduce this starting from the second step (that is, without opening a new LMMS instance). This behaviour occurs even if the VST is removed. @Pyrif Is this the behaviour you observe? Are you sure you can reproduce this before any VST is loaded?

did we ever test the fix that worked on Carla/MacOS? #4558 (comment)

In relation to this issue and/or #4183? I haven't, but I guess it would work. It would, however, have the unfortunate side-effect that VST embedding would no longer be possible. The issue appears to be with how Qt handles always-on-top behaviour with MDI windows that have native peers, i.e. not very well. I don't think we can address this for 1.2 without impacting existing functionality; I guess we just have to weigh up what is more important here, VST embedding or bug-free always-on-top behaviour. Given that one can turn off VST embedding, we have a workaround available already for those who need it, so I think we should leave this alone for the moment. Unless Pyrif demonstrates otherwise, I think this should be closed as a duplicate of #4183.

If I have the time and ambition at some point, I might look into the Qt bug itself, since they haven't got round to it yet.

[Spekular]

Closing and consolidating into #5433