5 ms·

I would look at it the other way. Why is the app so broken that it doesn't have support for multiple DPIs?

interpol_p 14y ago
The app shouldn't know about the DPI being used by the OS. It should be completely transparent to the app — this is not the app's responsibility.
- T-Winsnes 14y ago
  Yes and no, it should be transparent as in the app shouldn't be broken because someone has set their DPI to be different than usual. This becomes especially important when you have an application that can run on different devices with high and low DPI. Also, the 150% DPI setting is an accessibility feature for people with bad eye sight. All apps on windows desktop should support it. If your app doesn't, and setting it to 150% breaks your app, it's you fault for not spending the resources to support it. It might be a business decision, and that's cool, but it's still your choice. Can't blame it on anyone else.
  - interpol_p 14y ago
    If it's an accessibility feature only — and might break apps — then it shouldn't be the default setting on the Surface Pro. In a well designed operating system the application should not have to explicitly handle arbitrary DPI settings for correct touch/pointer input. An unsupported application should simply look blurry if it does not provide correct raster assets for the specified DPI. That's it.
    - ygra 14y ago
      The problem is that some applications tell the OS "Hey, I do support that" and they might even work fine for 125 % but fail for 150 (our product at work falls in that category). Basically everything you draw yourself on a pixel-based device context needs to be dpi-aware and people make mistakes, applications advertise capabilities that aren't there and not enough testing is being done. I can imagine though, that fixing that is now fairly high on their issue list. And Windows has used an automatically-determined scaling factor (based on display dpi) since Windows 7 so it's not exactly new.
- anonymfus 14y ago
  If app don't manifest itself as DPI aware then it's completely transparent because of so-called "DPI virtualisation". But some apps don't use system font rendering or want to draw lines precisely 1 pixel width or want to control anti-aliasing during zoom or so on, and such applications are either blured by DPI virtualisation (because 1 pixel width line is now 1.5 pixel at 150% scaling) or they manifest itself as "DPI aware" and then every pixel is rendered as told by app.
  - interpol_p 14y ago
    These apps should be drawing to a framebuffer managed by the operating system. Which should then be composited at the correct scale by the OS. One specific problem that arises on a Surface Pro is that the touch input on Civ 5 is off unless you set the DPI back to 100%. An app should not have to switch its touch/pointer handling just because the DPI changed. It seems like the low level input handling should have been wrapped by Windows 8 to handle these cases.

The app shouldn't know about the DPI being used by the OS. It should be completely transparent to the app — this is not the app's responsibility.

T-Winsnes 14y ago
Yes and no, it should be transparent as in the app shouldn't be broken because someone has set their DPI to be different than usual. This becomes especially important when you have an application that can run on different devices with high and low DPI. Also, the 150% DPI setting is an accessibility feature for people with bad eye sight. All apps on windows desktop should support it. If your app doesn't, and setting it to 150% breaks your app, it's you fault for not spending the resources to support it. It might be a business decision, and that's cool, but it's still your choice. Can't blame it on anyone else.
- interpol_p 14y ago
  If it's an accessibility feature only — and might break apps — then it shouldn't be the default setting on the Surface Pro. In a well designed operating system the application should not have to explicitly handle arbitrary DPI settings for correct touch/pointer input. An unsupported application should simply look blurry if it does not provide correct raster assets for the specified DPI. That's it.
  - ygra 14y ago
    The problem is that some applications tell the OS "Hey, I do support that" and they might even work fine for 125 % but fail for 150 (our product at work falls in that category). Basically everything you draw yourself on a pixel-based device context needs to be dpi-aware and people make mistakes, applications advertise capabilities that aren't there and not enough testing is being done. I can imagine though, that fixing that is now fairly high on their issue list. And Windows has used an automatically-determined scaling factor (based on display dpi) since Windows 7 so it's not exactly new.
anonymfus 14y ago
If app don't manifest itself as DPI aware then it's completely transparent because of so-called "DPI virtualisation". But some apps don't use system font rendering or want to draw lines precisely 1 pixel width or want to control anti-aliasing during zoom or so on, and such applications are either blured by DPI virtualisation (because 1 pixel width line is now 1.5 pixel at 150% scaling) or they manifest itself as "DPI aware" and then every pixel is rendered as told by app.
- interpol_p 14y ago
  These apps should be drawing to a framebuffer managed by the operating system. Which should then be composited at the correct scale by the OS. One specific problem that arises on a Surface Pro is that the touch input on Civ 5 is off unless you set the DPI back to 100%. An app should not have to switch its touch/pointer handling just because the DPI changed. It seems like the low level input handling should have been wrapped by Windows 8 to handle these cases.