Windows 8.1 DPI Scaling Enhancements

Using High DPI myself I have never experienced what everyone else seems to be talking about with applications breaking. (Unless you are talking about Windows XP)

Edit: It appears that Windows applications that don't support the High DPI interface are rendered then resampled as you say. So it's up to the app developer to support scaling, although you can disable the app resampling behaviour on a per app basis too.

Eg:

You have some icon, you might provide bitmap versions of it at: 8x8, 32x32, 64x64, 128x128, 256x256 (the exact sizes depend upon the desired size of the image when displayed combined with what DPI ranges you want to support well).

Based on your layout, the final pixel size occupied by that icon control might be 200x200 on a high res tablet, the OS will choose the 256x256 bitmap and downsample it slightly to fit 200x200. The same icon area might be 60x60 on a phone, so it'll chose the 64x64 and downsample that one a bit to fit 60x60.

I haven't done much iOS programming, but from what I understand it works pretty much the same except the sizes are more fixed at 1x/2x/4x because there is less DPI variation across iOS devices.

This way has downsides (makes the assets larger since you have multiple copies of each one), but generally works pretty well in practice and actually works better than vectors for some things (though vectors can scale up and down at will, if they aren't heavily 'hinted' you can easily lose important details that you don't want to lose at small sizes, with pre-rendered bitmaps you can adjust for this ahead of time).

http://msdn.microsoft.com/en-us/library/windows/desktop/ff68...

I guess the problem is that when 1 DIP = 1 pixel for almost everybody in almost every case you don't notice when you mix them up.

Contrast to something like NeXTStep, which evolved into OS X, started out with display hardware of 1120×832 (although grayscale). More importantly it used display postscript which is vector-based. Even though it came out in 1989 which was only 4 years after Windows 1.0, the computers that ran it were much, much more powerful than the PC of the time. The original NeXT computer was closer in performance to what a mid-range Windows 95 machine was (486DX/25MHz, 8MB RAM, 1024x768 graphics...)

I guess you have to deal with font sizes (handled by the system) you're own contraints ("this button is half this screen", "this screen is at most 800px" etc), and the user scaling your UI.

Before scaling was even an issue, I've seen a lot of app screwing the font and UI size pairing when launched on non english languages with different default fonts settings or wildly longer text(the app's own translated text that is). Throwing in a "what dpi is my screen?" variable to the equation must make things that much harder.

http://answers.microsoft.com/en-us/ie/forum/ie10-windows_8/w...

I've not played with 8.1 yet, but hopefully it's been addressed.

put in in fullscreen mode

Is there a reason outside of legacy code base that everything in the OS is not vector based?

Telling people to double up or deal with shitty performance is a much worse proposition than what Microsoft is doing.

Windows has had DPI-based scaling of user interfaces since Windows 95 where you would set your display DPI and all applications on the system would (theoretically) adapt. The problem is that app developers have historically been completely deficient in this regard; in practice they either hard-code pixel-perfect layouts (but don't lock the font sizes, so text gets cut off), or half-ass it and get the DPI scaling completely wrong by starting to implement it and then stopping. It has literally been possible for Win32 applications to do everything that a OSX/iOS Retina application does since 1995. This feature was even supported in Visual Basic!

In Windows Vista, Microsoft responded to this by adding a new system where unless an application explicitly told the window manager 'yes, I'm actually DPI aware', the window manager assumes that the app will completely muck up DPI scaling, and it renders to a lower-resolution window buffer and scales it up so that text/object sizes are appropriate for your display DPI. Despite this, there are still applications that tell the window manager 'I'm DPI aware!!!' when they're not. Note that this scaler uses an actual scaling algorithm, unlike Apple's nearest-neighbor, so text scaled up in this fashion remains perfectly readable (albeit blurry), unlike the complete mess Apple turns Cleartype text into.

In practice the problem here is ENTIRELY developers and consumers, not Microsoft. Consumers buy (and continue to buy) displays that have resolutions that are not an even integral multiple of some other display resolution, and continue to buy applications that are not correctly DPI aware. Developers respond to this by continuing to ship broken applications that don't respond correctly to display DPI.

Microsoft could do whatever they wanted, including directly mirroring Apple's approach, and none of this would change.

Apple's approach only works because they have a complete monopoly on their platform and they use it to force developers to waste resources on whatever changes they introduce - a new approach to DPI awareness and rendering that requires introducing 2x versions of all your UI bitmaps, a new sandboxing mechanism and app store that requires it, a new UI toolkit, new font rendering APIs, etc. Usually Apple at least uses this power to improve things for consumers, but it's naive to look at how Apple handled the Retina transition and say 'if only Microsoft had done that too' - the Retina transition was incredibly expensive for developers and continues to be expensive for end-users (by making shipped applications larger and potentially slower and definitely more complex).

Don't even get me started on the blatant stupidity Apple's approach to Retina introduced into HTML5/Canvas/WebGL. getImageDataHD and devicePixelRatio, hurray!