4 ms·
Android has been shipping arbitrary DPI support for longer than iOS or MacOS has supported the limited 2x HiDPI, and it doesn't have the issues you're talking a
by kllrnohj 5y ago
Android has been shipping arbitrary DPI support for longer than iOS or MacOS has supported the limited 2x HiDPI, and it doesn't have the issues you're talking about.
It's definitely possible to do, although retrofitting an existing UI toolkit & ecosystem is a massive challenge.
- astrange 5y agoIsn't the Android SDK older than iOS? Either way, it can't escape blurriness. There's bitmaps on this very page and if I zoom in the reply button misrenders. Actually it can't escape pixel cracks either, as I seem to remember OpenGL ES 1.0 including GL_LINES where the default width is 1px.
- kllrnohj 5y agoAndroids pixels are display pixels, there's no post-render scaling. So no pixel cracks, no blurriness, etc... Density is instead handled mostly at layout, as it should be.
- astrange 5y agoYou can't just make the windows bigger on a high res display, the text will be unreadably small.
- kllrnohj 5y agoOf course you can. Text only ends up unreadably small if your text is specified in pixels. Which on a density-aware toolkit (like Android's) it isn't. https://developer.android.com/training/multiscreen/screendensities https://developer.android.com/training/multiscreen/screenden... This is also best practice on many other platforms, too (eg, 'pt' and 'em' units). This is far less commonly followed on most toolkits, though, but it's the norm on Android.
- astrange 5y agoAnd now your controls are either blurry or don't match the text size or you redid them all in vector art. Text size controls are in iOS as an accessibility feature (dynamic type) but it's not always on and it can't be the approach to HiDPI.