On Mon Oct 30 09:50:45 2023 +0000, Alexandros Frantzis wrote:
Hi! The purpose of this branch is to allow applications to render at the physical resolution of a display (in the default "application" scaling mode). That is, when a Wine application draws 10 pixels, these will end up as 10 physical pixels on screen. The main reason I want this at this point, is to allow applications, typically games, to use the full physical resolution even on scaled outputs (including when becoming fullscreen). Without this change the compositor will unconditionally scale surfaces contents, so (depending on the Wine/Wayland size transformation details) the contents will be either presented as larger than expected or blurrier than expected. As the code stands now (before this MR), scaled HiDPI displays are not properly supported, even with unconditional compositor scaling, since we are mixing up physical and logical coordinates at various points (for scale=1 these match so this hasn't been a problem there).
Do I understand correctly, that with this change and on HiDPI
displays, Wine
windows (defaulting at 96dpi) will appear as small windows by default? This doesn't look very desirable to me?
Yes, but to be clear, that's just because we are rendering at physical pixel sizes, it's not that we are making them artificially smaller in some way. This matches current WineX11 behavior (both with native X11 and Xwayland). Not that matching WineX11 is always the best way to go, but at least people won't be surprised. As mentioned in the description, the plan is to have a driver registry option to set the scaling mode (app vs compositor) globally or per app, so users will be able to select the mode that suits their use case best, which is already more flexible than what WineX11 provides (if I have not missed something). We could make compositor scaling the default, although then I expect people with scaled outputs will be confused about why their favorite game doesn't render as expected in fullscreen. Ideally we would properly integrate Wayland support for HiDPI with the win32 DPI awareness modes, but that will require some more thought and not all modes are fully (or at all) implemented in Wine anyway.
Also, I don't know how well our DPI code is, but I haven't seen much activity on that side and I would not bet that it's doing super well (the look of winecfg with non-default DPI already gives me a hunch that it's not perfect). So IMO you're going into troubled waters if you want to rely on it.
I don't want to rely on this mechanism in particular, but I would like to allow applications to perform their own scaling (or no scaling), which requires that I avoid forcing compositor side scaling.
Still, I don't mind looking at this, but fwiw it feels a bit premature
to do this now. To sum up, here are my reasons for proposing this now:
- Allow apps/games to use the full resolution on scaled outputs, which are quite common these days (and it personally annoys me since I use such
scaling :)) (Secondary benefits) 2. It gives us an opportunity to remove the assumption that Wine coords == Wayland surface coords, sooner rather than later, before that assumption has sneakily permeated even more of the codebase. 3. The scaling infrastructure (incl. coordinate transformations) used here will be also used for emulating display mode changes, so it's more generally useful.
I'd like to support the argument that this would be great for gaming. I use a 4k display with 2x scaling and every time I start a game I have to disable scaling in sway and reposition all my screens because of this. HiDPI support for wine wayland would fix one of my main annoyances while gaming on wayland.