Comment by latitude | Hacker News Reader

Comment by latitude | Hacker News Reader

Parent Full thread

Just to be clear - supporting High-DPI on Windows is not as simple as adding scaled up resources. Instead, it is an absolutely royal pain.

For one, you can't just throw hires bitmaps into a resource section of .exe and expect them to magically work. There needs to be code that looks at current DPI and picks matching bitmap.

For two, standard DPI levels are 96, 120, 144 and 192, but guess what? All other values in between and above 192 are game too. In fact, there's a nice little slider in the Control Panel that encourages you to put it somewhere in between. This means that your code either needs to rescale bitmaps to match these odd DPIs or use the largest one that fits. In either case the result will look like butt.

For three - the dialog layout. If your dialogs have text that's longer than 3-4 words, the chances are that it will either overflow, underflow or wrap differently under different DPIs. This in turn means that you need to test dialog appearance with at least 4 different font sizes and Tahoma 8px for Windows XP. Do you know how hard it is to word a longish sentence so that it would fill about the same space with all 5 combinations? Really damn hard and very time consuming.

But wait! There's more.

Every app icon needs to exist in at least 9 sizes, like so - http://imgur.com/5Pe2ZV0 - and this would still miss some cases where Windows will scale an arbitrary chosen icon image and use it.

It really is a mess. However this is not something unexpected if you've been writing for Windows for a while. This mess is a routine.

> For three - the dialog layout. If your dialogs have text that's longer than 3-4 words, the chances are that it will either overflow, underflow or wrap differently under different DPIs. This in turn means that you need to test dialog appearance with at least 4 different font sizes and Tahoma 8px for Windows XP. Do you know how hard it is to word a longish sentence so that it would fill about the same space with all 5 combinations? Really damn hard and very time consuming.

I don't understand that one. If the text is going to be a different size because it's scaled with the DPI, then hasnt the dialog itself scaled equally as well?

All sizes in dialog templates are indeed specified in "dialog units", which are based on the metrics of the dialog's font. So in theory if you are to double the font size, all dialog elements would just double in size and all will be well.

In practice, this is not sufficiently accurate to accommodate text size differences when going from one font/size to another. It's just too crude.

For example - http://imgur.com/STtd8OQ

  Top is SegoeUI/9pt, standard for DPI of 96.
  Middle is SegoeUI/10pt, standard for DPI of 125.
  Bottom is Tahoma/8pt, standard for XP at 96.

See how bottom two trim "practice"? That shouldn't be happening, but it does.

So wouldn't you just force the font?

On Windows, requesting a particular font size is just a hope and a prayer. The OS will draw things at the size it thinks is best, with heavy-handed hinting, so the size of a rendered piece of text is quite non-linear with respect to font size: http://damieng.com/blog/2007/06/13/font-rendering-philosophi...

This makes it quite impossible for an application to implement a general solution to the problem. You pretty much have to treat HiDPI as another translation of the GUI with respect to sizing things.

The other thing to remember is that most likely less than 1-2% of your whole customer base is currently using high DPI monitors, so all these very high and very real costs are sometimes not possible in ROI, especially for more niche markets. It much like supporting IE6, or maybe IE5 for the 1% that still use it? Would you in a niche market compared to a mainstream app? This will change with time as these monitors become more common but right now the threshold is still very low compared to the costs.

That seems like a lowball estimate even today. If you go shopping for a new Windows computer or tablet in Best Buy or Staples or some other american store, maybe 1/3rd to 1/2 of what's on shelves is high DPI now, from the $400 tablets up to $1200 ultrabooks. Lenovo, Samsung, Asus, HP, all the big manufacturers have 2560x1440 or 3200x1800 ultrabooks and hybrids out, and even 1920x1080 tablets are set to 1.5x or 2x DPI scaling because those pixels are packed into 10" or smaller screens.

Tablets yes. Notebooks no. 'Ultrabooks', whatever they are, maybe. The majority of laptops up to 15" and ~$1200 are still 1366x768. Source: I recently went shopping for a laptop with roughly that budget. In fact, I don't think you can buy anything 15" beyond 1080p on that budget.

1-2% is a bit low.

I actually tested this several months ago for one my projects and it was about 5% (on a sample of few hundreds). That's a very respectable 1 in 20. Not that I disagree with your ROI point, it's just that playing well with non-default DPIs becomes progressively more important now.

But was your project more oriented towards a tech audience or the general population. Over a few hundred people, especially tech people, for example your very likely to get a very very low IE user base compared to the average user ;)

There's some bias, no doubt, and the sample is barely representative. But the thing is that there's lots of new hardware, like Thinkpads, that ships pre-configured with higher DPI. Drop by drop, but this will tilt the scales .. if it hasn't already.

I totally agree, all I'm saying is that the numbers aren't there yet for most software shops, especially if you consider the added costs.

I'd argue that its more akin to supporting IE 11 immediately after its launch - only a small % of your users use it currently, but you can expect the number to grow over time.

Reply on news.ycombinator.com