Fix positioning on linux when using non-1 scale factor#50
Fix positioning on linux when using non-1 scale factor#50Nephyrin wants to merge 1 commit intoSnosMe:masterfrom
Conversation
src/index.ts
Outdated
| } else if (isLinux) { | ||
| let scaledXY = screen.screenToDipPoint({ x: lastBounds.x, y: lastBounds.y }) | ||
| let scaledSize = screen.screenToDipPoint({ x: lastBounds.width, y: lastBounds.height }) | ||
| lastBounds = { width: scaledSize.x, height: scaledSize.y, ...scaledXY }; |
There was a problem hiding this comment.
I think you want
const tl = screen.screenToDipPoint({ x: lastBounds.x, y: lastBounds.y })
const br = screen.screenToDipPoint({ x: lastBounds.x + lastBounds.width, y: lastBounds.y + lastBounds.height })
lastBounds = { x: tl.x, y: tl.y, width: br.x - tl.x, height: br.y - tl.y }and check if this still work for you
There was a problem hiding this comment.
This version also works, though in X11 land there's no concept of per-monitor scaling so the ratio should be universal.
Doing testing with some prints with the game maximized, I see
Game on 2.0x scale monitor with a 1.5x monitor peer to the left:
Scaling from: 3840.0 / 2160.0 @ 5120.0, 0.0
Scaling to: 1920.0 / 1080.0 @ 2560.0, 0.0, RATIO 2.00
Game on 1.5x scale monitor with a 2.0x monitor peer to the right:
Scaling from: 5120.0 / 2880.0 @ 0.0, 0.0
Scaling to: 2560.0 / 1440.0 @ 0.0, 0.0, RATIO 2.00
Game on 1.5x scale monitor with a 1.5x monitor peer:
Now all the 1.5 scale monitors are shown the 1/1.5 coordinate world
Scaling from: 3840.0 / 2160.0 @ 3840.0, 0.0
Scaling to: 2560.0 / 1440.0 @ 2560.0, 0.0, RATIO 1.50
... So it seems like CEF/chromium is seeing a world where the monitors are physically different resolutions at the same ratio, which is probably how KDE pushes the concept of per-screen scaling down to X11 clients.
For wayland clients this would presumably be different, though using x+width per above would break as soon as a window's BR point was on a different display from TL. Presumably you could steal the ratio the TL point was scaled by and use it on the width/height values, but that's assuming the window is using the same coordinate space for both values -- KDE translates a window's scale factor based on its center point, so who knows what coordinates are actually correct.
I think either version is fine to merge now, and probably proper-wayland-support will need this all fixed anyway. (Also CEF reports it lacks proper wayland support for these functions, ha)
There was a problem hiding this comment.
I updated this with your version and my best-effort comment explaining what I think the situation is for future generations debugging this on wayland.
Feel free to edit/change further, though
screenToDipRect is not supported on linux, though screenToDipPoint is. CEF docs suggest neither works on wayland sessions. We expect the X11 case to always have a constant scale factor, so this should be sufficient there, but is only best-effort on future-wayland-supported CEF versions, and will likely need to mimic the windows code with screenToDipRect.
2 participants
Awakened PoE Trade gets the wrong window bounds in KDE 6.6 when scaling is active. This can be worked around with
--force-device-scale-factor=1, but this also creates unscaled UI in the app.screenToDipRect is not supported on linux, though screenToDipPoint is. In my testing with mixed-scaling displays, just translating via Point is always correct, including on e.g. overlapping monitors of different values. I suspect this is due to multi-screen coordinates being implemented more transparently on linux, but I didn't dig further.
Tested on KDE when forcing X11 via
XDG_SESSION_TYPE=x11 ./awakened-poe-trade --ozone-platform=x11