Oct. 30, 2023
4:55 a.m.
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: > 1. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4203#note_50151