| Summary: | Per window scaling with shift-drag on window border | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Jos van den Oever <jos> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | kde, nate, veqz |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Jos van den Oever
2022-02-16 12:07:22 UTC
Related issues: https://bugs.kde.org/show_bug.cgi?id=227284 also request per-window scaling as an accessibility feature. https://bugs.kde.org/show_bug.cgi?id=446674 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47 discuss how fractional scaling would improve crispiness and decrease graphical buffer size on Wayland. I sort of doubt it's feasible, as it would require buy-in from Wayland people. The change would need to be made there. Still, IMO there's a valid use case for this: XWayland apps. You could have them render at 1x scale and use their own existing X11 scaling support (which most of them have) to match whatever scale factor you use for your native Wayland apps. The linked Wayland protocol issue (47) has suggestions for adding per window scaling via additions such as `wanted_scale`, `set_client_scale`, `setting_client_scale`. Since the current method of scaling is blurry and resource intensive I hope that these additions will be picked up soon. E.g. if you have a 4k display with 1.25 scaling, the current scaling method on Wayland would give a 6144x3456 (4k / 1.25 * 2) buffer to a fullscreen application such as the always-present desktop background. That is a buffer that is 2.56x as large as a 4k buffer. Not fun. So Wayland has a big incentive to fix 47. The proposed additions could be used to implement this scale-by-dragging feature. Or vice-versa, this feature request could be one more reason to have those Wayland additions. Scaling windows up and down by dragging makes for wonderfully visual demo material besides simply being very handy. Perhaps it's easier to first implement it on X11. >Perhaps it's easier to first implement it on X11. Definitely not, we have no input redirection and all clients are aware of the geometry of other windows; if this doesn't match cleints everything explodes. > Wayland Whilst technically possible, it means a different co-ordinate system between compositor and clients. We did put some infrastructure for xwayland in the upcoming release so xwayland as a whole to have a different scale. (exposed differently to shift+drag). I only covered the protocols used by xwayland which is considerably smaller than all the wayland protocols but I have an idea of how much work is involved! Not impossible, not trivial. >E.g. if you have a 4k display with 1.25 scaling, the current scaling method on Wayland would give a 6144x3456 (4k / 1.25 * 2) buffer to a fullscreen application such as the always-present desktop background. That's changing. It's going to give you the same sized buffer starting soon. Lets revisit after this and the xwayland change and the fractional scaling branches have landed and see how much of a use-case remains. *** Bug 471265 has been marked as a duplicate of this bug. *** |