Native windows style is incompatible with QQuickWidget or other means of offscreen rendering

Take qtdeclarative/examples/quick/quickwidgets/quickwidget and change rotatingsquare.qml to something like:

import QtQuick
import QtQuick.Controls
Rectangle {
    id: root
    ComboBox {
        width: 200
        height: 300
    }
}

Run this on Windows with the default native windows style. Then resize or move the window with the QQuickWidget in it.

The result is a guaranteed assertion (that occurs in debug builds only, as it's a Q_ASSERT), because QQuickWidget is being pedantic by enforcing that there is no native window created for its offscreen QQuickWindow.

Given that QQuickWidget is the sole enabler for Creator and Design Studio for adding Qt Quick content their views, this makes using the windows style impossible there.

The problem originates from the styles being way too eager to call winId() on the "window", which probably is not resolved properly using QQuickRenderControl::renderWindowFor().

There are probably other similar issues. For example dpr(opt->window) with opt being a QStyleOption and dpr() being
static inline qreal dpr(const QWindow *w)

is not correct if window is a QQuickWindow.

Basically any logic doing anything with a QWindow in the native styles (or elsewhere) needs to:

• if it's a QQuickWindow, then QQuickRenderControl::renderWindowFor() needs to be called on it and the result should be used instead (it returns the QWindow for the top-level widget of the QQuickWidget, which is the true on-screen window, and not the QQuickWidget's associated offscreen QQuickWindow)

• that function can still return null (a Quick application may not have any native windows on screen at all, and must still render as expected, when redirected f.ex. into a texture), in which case sufficient fallback logic needs to be applied. For example, by assuming 1.0 for device pixel ratio or whatever is suitable.

There are two possible solutions here:
1) make QQuickWidget less pedantic (strictly speaking for platforms with actual windowing support it is not fatal at all if a QWindow-that's-not-shown has a backing native window, just perhaps a bit wasteful)
2) Find out where the appropriate renderWindowFor() calls need to be added on Controls/Styles. Currently investigating this.