4 ms·

It's incredibly hard to change course if the UI toolkits weren't designed for it in the first place. Android is still about the only OS with reliable density i

It's incredibly hard to change course if the UI toolkits weren't designed for it in the first place. Android is still about the only OS with reliable density independence. It's also the only one where things like DPI were an initial part of the UI system, and not something bolted on later. Windows has been trying to retrofit density independence for nearly a decade now, and it's still pretty hit or miss. Apple didn't bother trying at all, and has been more successful at pretending it works (so scale rendering by whole numbers only, then fractionally scale the resulting image to the actual display size). Web browsers mostly went the Apple route, but we all also regularly expect pinch/zoom scaling to fix any glaring issues anyway and just accept it's kinda janky. Linux... well, Linux is still struggling with the basics of putting stuff on screen (Wayland vs. X11). I wouldn't hold my breath for that ecosystem to get this UX refinement working well anytime soon. Especially not across the many UI widget systems, window managers with differing border decorations, DEs, etc...

int_19h 5y ago
Windows has had the necessary bits for DPI independence since the 90s - it's why stuff like "dialog units" is a thing. The problem, as usual, is getting the apps to actually use it.
- kllrnohj 5y ago
  "dialog units" seems to be about the size of the system font, not about DPI independence. Things like WM_DPICHANGED seem to only really show up in Windows 8+, with some stuff like LOGPIXELSX showing up as "early" as Windows 2000 but doesn't look very complete.
  - int_19h 5y ago
    The size of the system font was basically a proxy for DPI. If you set scale to higher than 100% in, say, Win2K, it would also increase that size. (This doesn't handle multi-monitor setups well, since font size would be the same for them all. But multiple monitors were not exactly common back then.) WM_DPICHANGED is a late addition, yes, but it's only necessary for the apps to dynamically reflow if the user changes that setting. Before it showed up, you'd have to restart the app for it to register the new value - but that does not preclude DPI independence as such. The real problem was that almost everything in Win32 outside of CreateDialog uses device pixels to position. You were supposed to use GetDialogBaseUnits and/or MapDialogRect manually to get the correct values, and very few apps did. For another early example, Visual Basic (VB6, pre-.NET, so we're talking 1998) measured everything in twips.
    - kllrnohj 5y ago
      > The size of the system font was basically a proxy for DPI. Not entirely. The font size can still be changed independently of the DPI, and not everything should be scaled as a result. Things like dividing lines and padding probably shouldn't be scaled when the font size is increased. You still need a distinct DIP value independent of scaled font size. So the value of 'dp' vs. 'sp' in Android terms, which it looks like Windows' now also has that distinction. And yeah this is ignoring that things like the visual winforms tool in Visual Studio really just wanted to operate in fixed positions, and just getting things to work when the window was resized wasn't always intuitive or obvious. So even if the APIs were there, the ecosystem definitely didn't care about it and Microsoft's own tools definitely didn't help.
      - int_19h 5y ago
        If I remember correctly, the system font size couldn't be changed independently of the DPI, at least not in a supported way. You could change it yourself on a per-window basis, but a well-behaved app is not supposed to do that. Fixed layouts is orthogonal to all that - so long as those fixed layouts are defined in DPI-independent units, they will scale just fine. FWIW in WinForms (and also Delphi VCL, where this originated) you'd normally use anchors to design layouts that scale when the window is resized. Granted, it's nowhere near as flexible as proper layout containers - which WinForms (2.0+) also has, and which the visual form designer also supports, although it can be a pain to work with them.
  - int_19h 5y ago
    Oh, and LOGPIXELSX/Y showed up much earlier than Win2K. If you're getting that from MSDN, keep in mind that 2K is basically as early as the docs go, even if the actual API is much older. For example, it says the same for CreateWindow, even though that one goes all the way back to Windows 1.0.

int_19h 5y ago

Windows has had the necessary bits for DPI independence since the 90s - it's why stuff like "dialog units" is a thing. The problem, as usual, is getting the apps to actually use it.

kllrnohj 5y ago
"dialog units" seems to be about the size of the system font, not about DPI independence. Things like WM_DPICHANGED seem to only really show up in Windows 8+, with some stuff like LOGPIXELSX showing up as "early" as Windows 2000 but doesn't look very complete.
- int_19h 5y ago
  The size of the system font was basically a proxy for DPI. If you set scale to higher than 100% in, say, Win2K, it would also increase that size. (This doesn't handle multi-monitor setups well, since font size would be the same for them all. But multiple monitors were not exactly common back then.) WM_DPICHANGED is a late addition, yes, but it's only necessary for the apps to dynamically reflow if the user changes that setting. Before it showed up, you'd have to restart the app for it to register the new value - but that does not preclude DPI independence as such. The real problem was that almost everything in Win32 outside of CreateDialog uses device pixels to position. You were supposed to use GetDialogBaseUnits and/or MapDialogRect manually to get the correct values, and very few apps did. For another early example, Visual Basic (VB6, pre-.NET, so we're talking 1998) measured everything in twips.
  - kllrnohj 5y ago
    > The size of the system font was basically a proxy for DPI. Not entirely. The font size can still be changed independently of the DPI, and not everything should be scaled as a result. Things like dividing lines and padding probably shouldn't be scaled when the font size is increased. You still need a distinct DIP value independent of scaled font size. So the value of 'dp' vs. 'sp' in Android terms, which it looks like Windows' now also has that distinction. And yeah this is ignoring that things like the visual winforms tool in Visual Studio really just wanted to operate in fixed positions, and just getting things to work when the window was resized wasn't always intuitive or obvious. So even if the APIs were there, the ecosystem definitely didn't care about it and Microsoft's own tools definitely didn't help.
    - int_19h 5y ago
      If I remember correctly, the system font size couldn't be changed independently of the DPI, at least not in a supported way. You could change it yourself on a per-window basis, but a well-behaved app is not supposed to do that. Fixed layouts is orthogonal to all that - so long as those fixed layouts are defined in DPI-independent units, they will scale just fine. FWIW in WinForms (and also Delphi VCL, where this originated) you'd normally use anchors to design layouts that scale when the window is resized. Granted, it's nowhere near as flexible as proper layout containers - which WinForms (2.0+) also has, and which the visual form designer also supports, although it can be a pain to work with them.
- int_19h 5y ago
  Oh, and LOGPIXELSX/Y showed up much earlier than Win2K. If you're getting that from MSDN, keep in mind that 2K is basically as early as the docs go, even if the actual API is much older. For example, it says the same for CreateWindow, even though that one goes all the way back to Windows 1.0.