The work involved a considerable architectural refactoring to make it possible to support the per-window scaling design of the Wayland protocol, without breaking the standard per-display scaling implemented in Chromium.
That’s…. really weird. Per-display scaling on Windows and (most impls in) X is actually reported to you on a window-by-window basis, so I would think the natural implementation is to use that directly. Sure, it is configured by the user on a per display basis, but is reported to your application window by window, since windows can be dragged across display boundaries individually. It sounds like Chromium might have made some unwarranted assumptions in the past about that. I would like to know more about this. (My own dives into the Chromium ozone/X11 code has revealed quite a few places where they break standard conventions with unwarranted assumptions, they basically have not only their own from-scratch toolkit but also their own partial window manager too, which easily conflicts with the user’s real window manager, which I find hard to explain. Maybe related to evolution of ChromeOS? idk. Anyway, it wouldn’t surprise me that their scaling lives in its own strange new world too, but still would be interested in learning more.)
One of the linked issues at the end references a ScreenDetailed.devicePixelRatio javascript api they wanted to implement. Ugh, why is that even in javascript? Looks browser specific to Edge, but… why? window.devicePixelRatio makes sense, that’s useful information - and of course, that’s per-window! - but web apis just seem to throw a lot at the wall and see what sticks, just the problem is then you can locked into certain assumptions with the outside world too.
That’s…. really weird. Per-display scaling on Windows and (most impls in) X is actually reported to you on a window-by-window basis, so I would think the natural implementation is to use that directly. Sure, it is configured by the user on a per display basis, but is reported to your application window by window, since windows can be dragged across display boundaries individually. It sounds like Chromium might have made some unwarranted assumptions in the past about that. I would like to know more about this. (My own dives into the Chromium ozone/X11 code has revealed quite a few places where they break standard conventions with unwarranted assumptions, they basically have not only their own from-scratch toolkit but also their own partial window manager too, which easily conflicts with the user’s real window manager, which I find hard to explain. Maybe related to evolution of ChromeOS? idk. Anyway, it wouldn’t surprise me that their scaling lives in its own strange new world too, but still would be interested in learning more.)
One of the linked issues at the end references a
ScreenDetailed.devicePixelRatiojavascript api they wanted to implement. Ugh, why is that even in javascript? Looks browser specific to Edge, but… why? window.devicePixelRatio makes sense, that’s useful information - and of course, that’s per-window! - but web apis just seem to throw a lot at the wall and see what sticks, just the problem is then you can locked into certain assumptions with the outside world too.