In D6952#129544, @davidedmundson wrote:

That almost certainly breaks high Dpi support.

That's what I feared when doing the change, though the unit test which does high dpi still works.

What we can do is check the buffer scale. If it's 1 and the clientSize is different to the bufferSize use the clientSize - in all other cases the bufferSize.

My window scaling test still works because (in retrospect) it's really stupid.

I use render an entirely blue square.

If you only show the top quarter of that it's still an entirely blue square.

I should render the Japanese flag or something to be useful. Unfortunately that means forking/extending renderAndWaitForShown.

In D6952#129558, @davidedmundson wrote:

My window scaling test still works because (in retrospect) it's really stupid.

I use render an entirely blue square.

lol, right.

If you only show the top quarter of that it's still an entirely blue square.

I should render the Japanese flag or something to be useful. Unfortunately that means forking/extending renderAndWaitForShown.

we could have an overload which takes a QImage instead of a QColor

Seems ok, but I'm lost as to why Xwayland clients have a different buffer size in the first place.

In D6952#129679, @davidedmundson wrote:

Seems ok, but I'm lost as to why Xwayland clients have a different buffer size in the first place.

It is due to the reparenting of the window to support window decorations. The actual window becomes larger. You can find similar adjustments in the code building the vertices for OpenGL.

ok to go in?