QML rendering glitch when changing monitor setup on Windows 10

This bug was encountered on several Windows 10 devices but not on Windows 11. No obvious link was found to a specific Windows version or graphics driver. Connecting an external monitor or changing between duplicate/extend modes causes a significant glitch in QML window rendering and breaking user mouse interaction. More details below.

On affected devices, the reproduction rate is 100% using the steps below.

The attached screenshots are for Qt examples. From left to right:

• https://github.com/qt/qtdeclarative/tree/dev/examples/qml/dynamicscene
• https://github.com/qt/qtdeclarative/tree/6.5.0/tests/manual/quickcontrols/swipetoremove
• https://github.com/qt/qtdeclarative/tree/6.5.0/examples/quick/customitems/dialcontrol

Environment:

A Windows 10 device with an second/external monitor connected.

Steps:

• Start QML application.
• Connect external monitor, either physically or by toggling between Duplicate/Extend modes.

Result (see attached images):

• Window frame is resized correctly to adapt to effective DPI.
• Window content is rendered using wrong location/DPI.
  • It ignores window decorations (as if the title bar geometry is part of the client area).
  • The render size is different from actual window size leaving black/glitched areas in the rest of the window.
  • Window remains in glitched state until it's either resized, maximized/unmaximized or its flags are changed.
  • Rendered UI does not match geometry used for mouse interactions.
  • Example: Hovering/clicking on a button, it looks like there is a "ghost" button reacting to mouse pointer. The rendered button is shifted from the ghost one.

Current workaround on user side:

• Upon detecting screen setup change, a quick change in width or height by +1 then -1 then back to original size works when the window is in "restore" state (i.e. not maximized).
• This isn't an option for maximzed windows. The window would have to be unmaximized then maximized again.

Investigated solution:
Triggering ApplicationWindow to do an internal relayout(), by e.g. changing its header/footer, doesn't solve the issue. This isn't a layout issue.
It seems more likely to be a rendering problem. (Perhaps the scene graph isn't being invalidated when it should?)

Before glitch:

With glitch: