4 ms·

Android is like that too. Some devices have non-integer pixel densities (multipliers or device pixel ratios or scaling factors or whatever term you prefer), esp

Android is like that too. Some devices have non-integer pixel densities (multipliers or device pixel ratios or scaling factors or whatever term you prefer), especially 1.5x aka "hdpi" that was popular around 2011. You can provide separate resources for each pixel density if you still use bitmap graphics for some reason. Oh and there's also "ldpi", which is something like 0.75x, though there were very few devices with it. With how advanced macOS graphics stack is, I don't understand why does Apple not do this, instead insisting on using integer multipliers. Some iPhone models, too, render the UI at 3x and then downscale it to fit the screen. Even more curious is the fact that they have returned it as a float for as long as retina displays were a thing: https://developer.apple.com/documentation/appkit/nsscreen/1388385-backingscalefactor?language=objc https://developer.apple.com/documentation/appkit/nsscreen/13... edit: one important difference I forgot to mention. On Android, all draw calls on the Canvas, and all view dimensions and other things like text sizes, always take physical pixels. It's your job to multiply and round everything correctly. On macOS and iOS, all graphics APIs take "points", which are those logical pixels you get after the scaling is applied, "density-independent pixels" as Android calls them. I guess Apple thought it would make it easier to adapt existing apps to retina displays. Android has always supported UI scaling, so there was no problem designing the API the way it is.

ridiculous_fish 5y ago
I worked on the Cocoa frameworks back when the hope was arbitrary scaling. The short answer to your question is "rounding." At 1.5x, a box of length 3 occupies 4.5 physical pixels. Either one side of the box will be blurry, or the box must get resized to align with physical pixels, which can cause mis-centering of text or icons, or unexpected clipping or truncation. There was also a lot of custom layout code in existing apps, both first and third party, which just didn't work at arbitrary scale factors because it was never tested. Yet another complication is that apps are expected to handle scale changes, e.g. if the user drags a window from one display to another. Android doesn't have to deal with this. After years of trying to make it work, Apple basically gave up and did the scaling in WindowServer.
- diskzero 5y ago
  Ah yes, the Hi-DPI days. I left Apple before all of that was sorted out. I assume all of the code dealing with scaling was just removed from the frameworks?
- grishka 5y ago
  > I worked on the Cocoa frameworks The thing I love about HackerNews is how you can casually run into people who worked on things you've been using every day for the last 10 years. > The short answer to your question is "rounding." Yeah, on Android, you're supposed to round yourself. View dimensions are integers, so you have to, but graphics APIs take floats, you don't strictly have to, but you want to anyway. Even though there's no such thing as pixel-perfect on AMOLED displays thanks to their subpixel layout. When you use XML and specify `25dp`, the system does the rounding. > Android doesn't have to deal with this. Oh it does! Though it deals with this in a lame way: your activity with all its views gets destroyed and recreated for a "configuration change" unless you've explicitly specified that you can handle this specific kind of change. Density doesn't change often, but the possibility is certainly there. I remember how around 2013 there was this bizarre device. It was a phone, but it came with a tablet you could dock it into. The tablet contained only a screen and a battery. The screens on the phone and on the tablet had different densities. There were bug reports about my app not handling these transitions correctly, presumably because I was dumb back then. I can imagine something similar happening with the new hotness, foldable devices, where the external and internal screens could have different densities. And while I have you, one question. Why does macOS have the coordinate system origin in the bottom left? I've always found that bizarre, especially when iOS does use the usual top left.

ridiculous_fish 5y ago

I worked on the Cocoa frameworks back when the hope was arbitrary scaling. The short answer to your question is "rounding." At 1.5x, a box of length 3 occupies 4.5 physical pixels. Either one side of the box will be blurry, or the box must get resized to align with physical pixels, which can cause mis-centering of text or icons, or unexpected clipping or truncation. There was also a lot of custom layout code in existing apps, both first and third party, which just didn't work at arbitrary scale factors because it was never tested. Yet another complication is that apps are expected to handle scale changes, e.g. if the user drags a window from one display to another. Android doesn't have to deal with this. After years of trying to make it work, Apple basically gave up and did the scaling in WindowServer.

diskzero 5y ago
Ah yes, the Hi-DPI days. I left Apple before all of that was sorted out. I assume all of the code dealing with scaling was just removed from the frameworks?
grishka 5y ago
> I worked on the Cocoa frameworks The thing I love about HackerNews is how you can casually run into people who worked on things you've been using every day for the last 10 years. > The short answer to your question is "rounding." Yeah, on Android, you're supposed to round yourself. View dimensions are integers, so you have to, but graphics APIs take floats, you don't strictly have to, but you want to anyway. Even though there's no such thing as pixel-perfect on AMOLED displays thanks to their subpixel layout. When you use XML and specify `25dp`, the system does the rounding. > Android doesn't have to deal with this. Oh it does! Though it deals with this in a lame way: your activity with all its views gets destroyed and recreated for a "configuration change" unless you've explicitly specified that you can handle this specific kind of change. Density doesn't change often, but the possibility is certainly there. I remember how around 2013 there was this bizarre device. It was a phone, but it came with a tablet you could dock it into. The tablet contained only a screen and a battery. The screens on the phone and on the tablet had different densities. There were bug reports about my app not handling these transitions correctly, presumably because I was dumb back then. I can imagine something similar happening with the new hotness, foldable devices, where the external and internal screens could have different densities. And while I have you, one question. Why does macOS have the coordinate system origin in the bottom left? I've always found that bizarre, especially when iOS does use the usual top left.