The buffer for a XWayland window is larger than the actual size. Thus
we need to use the clientSize as reference, not the buffer size.
BUG: 382748
davidedmundson |
KWin | |
Plasma |
The buffer for a XWayland window is larger than the actual size. Thus
we need to use the clientSize as reference, not the buffer size.
BUG: 382748
Test passes
No Linters Available |
No Unit Test Coverage |
That almost certainly breaks high Dpi support.
(Though not for xwayland windows which will always be scale 1)
I'll take a look at the bug, and see if we can come up with something else.
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.
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.
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.