5 ms·
OS X has the best highdpi implementation at the moment, and use the pixel scaling approach. It seems to work well there.
by bla2 12y ago
OS X has the best highdpi implementation at the moment, and use the pixel scaling approach. It seems to work well there.
- legulere 12y agoThe problem is that the fallback of scaling twice and getting a bit pixelated stuff isn't working all the time under gnome
- brianpgordon 12y agoThe extent to which the third party software ecosystem supports Retina is, I think, the greatest strength of OS X at the moment.
- bla2 12y agoProbably because the pixel scaling method requires much less works by developers.
- chris_wot 12y agoIt does work well. The other day, there was an article on someone who did an extreme test on pixel scaling, and an Apple software engineer wrote the following comment: https://news.ycombinator.com/item?id=8634895 https://news.ycombinator.com/item?id=8634895 The part of the comment that I found the most interesting was his take on a solution: 1. Make everything vectors. You'll have to choose between weird antialiasing artifacts and potential pixel cracks; either way things will look bad. And you'll encounter bitmaps eventually, and have to deal with the necessities of resampling and pixel aligning at that point. 2. Scale only to integral sizes, and resample. You'll avoid antialiasing and pixel alignment issues, but pay a performance penalty, and things may look slightly blurry.
- protomyth 12y agoI'm curious about this. Aren't fonts vector files with some hinting?
- Someone 12y agoI do t know about the "some", but that is what that Apple engineer says: Which leads to the problem of centering. I wish to center a bitmap image within a button's border. The image is 101 logical points high, and the border is 200 logical points high. With a 2x scale factor, I can center absolutely, and still be aligned to device pixels. With a 1x, 1.25, 1.33, etc. scale factor, centering will align me on a partial pixel, which looks like crap. So I have to round. Which way? If the goal is "make it look good," then the answer is "whichever way looks good," which depends on the visual style of the bezel, i.e. whether the top or bottom has more visual weight. So now we need hinting. And that's where things start to get really nasty. In order to make things look good at arbitrary resolutions, we want to round to device pixels. But the rounding direction is not a local question! Consider what happens if we have two visual elements abutting in logical coordinates, and they round in opposite directions: now there's a device pixel between them. That's very visible: you get a pixel crack! So you have to coordinate rounding. Question: even with hinting, is it actually possible to make a font where two glyphs align perfectly without white space between them? WPF is a good example of a framework that attempted resolution independence and encountered this problem. Initially it has the "SnapsToDevicePixels" property, which triggers rounding behavior at draw time. But draw time is too late, because of the "abutting elements rounding in opposite directions" problem. So they introduced the "UseLayoutRounding" property, which does...something. And the guidance is basically "turn it on and see if it helps, if not, disable it." Great. I think a way out of this is way higher DPI with some blurring as the last step. That's what print does. At 1000 or 2500 DPI nobody will notice aliasing anymore, and he blurring would take care of small cracks between objects that supposedly are abutting, make cases where two objects that shouldn't accidentally do overlap less obnoxious, etc.