15 ms·

> Both 14" and 16" have 254 PPI, up from ~220 Which also means they finally support more screen real estate at native 2x! Since 2016 the 13" MacBooks retained

> Both 14" and 16" have 254 PPI, up from ~220 Which also means they finally support more screen real estate at native 2x! Since 2016 the 13" MacBooks retained their 2560x1600 panels but shipped by default in a "looks like 1440x900" mode, which renders a 2880x1800 frame and does a non-integer scale down to the panel's native resolution, trading sharpness for extra space. I hate the slight fuzzy look so I run mine at native 2x (e.g. "looks like 1280x800"), but it makes things pretty cramped. These new screens can run native 2x at the "looks like 1440x900" res (other rather, "looks like 1512x982"). Very welcome improvement.

deleted 5y ago
[deleted]
seanmcdirmid 5y ago
> which renders a 2880x1800 frame and does a non-integer scale down to the panel's native resolution, trading sharpness for extra space. This isn't how it really works. It doesn't render 2880x1800 frame and scale down, it will just render at the resolution given for the size of the widgets desired. Any modern GPU can do that, the only time down scaling is needed is if you have a higher resolution bitmap that you want rendered at a lower resolution (or you can scale up, anyways, modern applications should not be rendering fixed sized bitmaps to ever need to do that). Edit: never mind, that is how it actually works. I never realized MacOS never got true resolution independence like WPF.
- kuschku 5y ago
  Gnome actually always render a full framebuffer at integer scales and then downscale in GPU with bilinear scaling. 4K output, 1.5× scale means 6K framebuffer scaled to 4K. That's sadly how it works at least on Gnome, and Gnome says they've copied it 1:1 from MacOS.
  - hollerith 5y ago
    >Gnome actually always No, not always: when XFree86 and XWayland are out of the picture (i.e., when the app is talking directly to the Wayland protocol) there is no downscaling or upscaling at all. So, for example on Fedora 34 (my daily driver) if you say gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" , then a new line (named "Scale") appears in the "Displays" pane of the Gnome "Settings" app. If you use that new line to set the scaling factor to 125% or 150% or 175%, then start google-chrome-stable or google-chrome-unstable with the flags -enable-features=UseOzonePlatform and -ozone-platform=wayland, then navigate to the page containing this comment, the "Y" in the upper left corner is a little blurry -- enough so that most people with non-hiDPI displays should be able to tell -- but everything else on the page, including the white box around the white "Y" and emphatically all the text is rendered directly at the correct resolution. This is because on a modern OS, the fonts are stored as resolution-independent mathematical descriptions of curves (splines, to be exact) that can be rendered cleanly at any resolution. And rounded corners specified by browser CSS or in GTK 3 or GTK 4 (the versions of GTK capable of communicating directly in the Wayland protocol) are specified in a resolution-independent way. And if the aforementioned white "Y" were a SVG file instead of a PNG file, it wouldn't be blurry either (but don't bother changing it, dang, it is fine the way it is). And all the Gnome apps, e.g., the aforementioned Settings app, e.g., Gnome Terminal, on my install are non-blurry at fractional scaling factors.
  - Joeri 5y ago
    To my knowledge windows is the only OS which renders the widgets at fractional scales and doesn't scale the output, but it only does it for apps which implement DPI awareness correctly. Some apps advertise to the OS they support DPI awareness, but then render controls at the wrong size. Others are GDI-based and don't support DPI awareness at all, and those are rendered 1x and scaled fractionally, which looks like a blurry mess.
    - kuschku 5y ago
      Android and KDE use this method as well, which is very awesome as it provides the best performance and the best quality.
    - rsynnott 5y ago
      Interestingly, early versions of MacOS 10 supported this as a hidden feature. It never really worked properly.
      - Joeri 5y ago
        It has never worked properly on windows either, but that hasn't prevented microsoft from shipping it. In fact, for a long time they didn't support per-monitor DPI awareness in the OS, so people with mixed DPI multi monitor setups had applications render at the wrong size or blurry when they moved them across. This was fixed in one of the windows 10 feature updates, and after that it was a patient wait for software to implement support for it. I believe MS Office 2019 was the version where it finally got correct support for it.
        danudey 5y ago
        When the MMO Star Wars: The Old Republic launched, I tried the beta and kept having issues where it would launch to a black screen, wait, and then crash. Someone, somewhere, figured out that the game only runs properly if you have the text scaling at 100%; I had it at 150% because I was playing on a TV and the screen was unreadable at 100%. I have to wonder what Microsoft did with text scaling that it broke a DirectX game.
    - 5y ago
  - kmeisthax 5y ago
    Apple and GNOME do this to avoid rounding errors when working in scalable layouts defined as screen-width percentages. Web browsers have accumulated all sorts of tricks and hacks to ensure that, say, floating four 25% width columns always adds up to the same width as a 100% column. This isn't a particular failing of CSS or the web - though CSS floats absolutely make this so much of a problem that browsers have to actually correct for this when users scale pages. Exposing a 1x design to non-integer scale factors fundamentally runs the risk of breaking it - you will get odd pixel gaps or misalignments which would not occur at integer scales, because the virtual pixel coordinates no longer line up with actual screen pixels.
    - kuschku 5y ago
      Qt has done that for many years, so has Android, so has Windows. Only macOS and Gnome don't, because they value single-pixel alignment errors more than the massive performance issues and reduced sharpness their solutions cause.
      - vetinari 5y ago
        And Qt after all those years does not work correctly in HiDPI. Not even on Windows. Unlike macOS and Gnome, which do.
        kuschku 5y ago
        Gnome does NOT work correctly in HiDPI. I’ve got 3 systems with 1.5x scale, and Qt handles them perfectly fine (even with per-monitor separate scaling). While Gnome absolutely does not. Either I get absolutely unreadable tiny 1x, or I get absolutely unusable 2x with no space for anything. (That said, Qt on Windows handles per-screen scale factors very weirdly, especially with applications using pixel values)
        nextaccountic 5y ago
        In my screen, 1x and 2x are both inadequate, but I'm using Gnome on Wayland on 1.25 scaling right now. Gnome can do fractional scaling. You just need to configure it with a gsettings command: https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fractional-scaling.html https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fr... https://wiki.archlinux.org/title/HiDPI#Fractional_scaling https://wiki.archlinux.org/title/HiDPI#Fractional_scaling Or using gnome-tweaks. Then, on display settings, it should show up the new scaling configs. And, in Gnome it's very sharp, with zero blurring! It was somehow sharper than whatever KDE was doing when I tested it some months ago.
- AzN1337c0d3r 5y ago
  No he's right, it renders to a 2x resolution off screen with hidpi assets (2x resolution icons, double-size text, etc) and then does downsampling back to your screen resolution 2560x1600 for 13 inches, 2880x1800 for 15 inch, 3072x1092 for 16-inch MBPs.
- csande17 5y ago
  macOS does in fact do this kind of non-integer bitmap scaling. It's got nothing to do with what the GPU is capable of; Apple's UI framework can't do layout or text rendering at anything but "1x", "2x", or "3x" densities. This is also why the first Catalyst apps looked really blurry and bad on non-Retina displays; Apple applied a non-integer scale to the final rendered frames to work around UIKit not being able to draw the right size widgets.
chrismorgan 5y ago
I have always been utterly baffled by Apple’s approach to high DPI. They ship some of the best panels around, and then they kneecap them by using the most idiotic scaling scheme imaginable that guarantees that it’s worse than a low resolution panel for some tasks that want precision and uglier on things like single pixel lines which crop up a lot in e.g. web content, because pixel precision is impossible. Microsoft managed to do it right (though mixed-DPI took a couple of attempts), despite having no real power over developers. Meanwhile, Apple, who are in a position to sternly tell their developers to do it right or their software will break (and do so far more frequently than Microsoft), … caved and did it terribly? And do they even support real mixed DPI, or do they just fake it by rendering at the higher scale and downsampling to the other?
- stephen_g 5y ago
  This doesn't gel with my experience at all. Yes, past MacBooks weren't necessarily integer scaling (with this new display the default setting and what most people use will be though as far as I understand), and non-integer scaling is not ideal. But on my last two MacBooks at least the screen is visually plenty sharp, and looks way, way, better than the regular-DPI external monitors I still have (whether the external monitor is connected to the Mac or a Windows PC). And above all, my experience with Mac is that high-DPI has actually worked from the beginning, whereas on Windows I still have some apps that break if the scaling is not set to 100%! Even right at the start, old apps would look a bit blurry but would still at least be in the correct proportions on macOS, whereas with the Windows scaling a lot of stuff just wouldn't work!
  - chrismorgan 5y ago
    I have no direct personal experience on high-DPI macOS. For Windows, I’ve only come across a couple of apps that claimed to support high DPI but severely mangled it, and they both got fixed before long; and a few others that had minor problems, e.g. opening windows at unscaled sizes so that you had to resize them, or rendering small icons. And to be sure there are various DPI-unaware apps, probably far more than on macOS (linked to why Apple was in the perfect position to implement and impose proper fractional scaling), but that’s not a serious problem either.

deleted 5y ago

[deleted]

seanmcdirmid 5y ago

> which renders a 2880x1800 frame and does a non-integer scale down to the panel's native resolution, trading sharpness for extra space. This isn't how it really works. It doesn't render 2880x1800 frame and scale down, it will just render at the resolution given for the size of the widgets desired. Any modern GPU can do that, the only time down scaling is needed is if you have a higher resolution bitmap that you want rendered at a lower resolution (or you can scale up, anyways, modern applications should not be rendering fixed sized bitmaps to ever need to do that). Edit: never mind, that is how it actually works. I never realized MacOS never got true resolution independence like WPF.

kuschku 5y ago
Gnome actually always render a full framebuffer at integer scales and then downscale in GPU with bilinear scaling. 4K output, 1.5× scale means 6K framebuffer scaled to 4K. That's sadly how it works at least on Gnome, and Gnome says they've copied it 1:1 from MacOS.
- hollerith 5y ago
  >Gnome actually always No, not always: when XFree86 and XWayland are out of the picture (i.e., when the app is talking directly to the Wayland protocol) there is no downscaling or upscaling at all. So, for example on Fedora 34 (my daily driver) if you say gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" , then a new line (named "Scale") appears in the "Displays" pane of the Gnome "Settings" app. If you use that new line to set the scaling factor to 125% or 150% or 175%, then start google-chrome-stable or google-chrome-unstable with the flags -enable-features=UseOzonePlatform and -ozone-platform=wayland, then navigate to the page containing this comment, the "Y" in the upper left corner is a little blurry -- enough so that most people with non-hiDPI displays should be able to tell -- but everything else on the page, including the white box around the white "Y" and emphatically all the text is rendered directly at the correct resolution. This is because on a modern OS, the fonts are stored as resolution-independent mathematical descriptions of curves (splines, to be exact) that can be rendered cleanly at any resolution. And rounded corners specified by browser CSS or in GTK 3 or GTK 4 (the versions of GTK capable of communicating directly in the Wayland protocol) are specified in a resolution-independent way. And if the aforementioned white "Y" were a SVG file instead of a PNG file, it wouldn't be blurry either (but don't bother changing it, dang, it is fine the way it is). And all the Gnome apps, e.g., the aforementioned Settings app, e.g., Gnome Terminal, on my install are non-blurry at fractional scaling factors.
- Joeri 5y ago
  To my knowledge windows is the only OS which renders the widgets at fractional scales and doesn't scale the output, but it only does it for apps which implement DPI awareness correctly. Some apps advertise to the OS they support DPI awareness, but then render controls at the wrong size. Others are GDI-based and don't support DPI awareness at all, and those are rendered 1x and scaled fractionally, which looks like a blurry mess.
  - kuschku 5y ago
    Android and KDE use this method as well, which is very awesome as it provides the best performance and the best quality.
  - rsynnott 5y ago
    Interestingly, early versions of MacOS 10 supported this as a hidden feature. It never really worked properly.
    - Joeri 5y ago
      It has never worked properly on windows either, but that hasn't prevented microsoft from shipping it. In fact, for a long time they didn't support per-monitor DPI awareness in the OS, so people with mixed DPI multi monitor setups had applications render at the wrong size or blurry when they moved them across. This was fixed in one of the windows 10 feature updates, and after that it was a patient wait for software to implement support for it. I believe MS Office 2019 was the version where it finally got correct support for it.
      - danudey 5y ago
        When the MMO Star Wars: The Old Republic launched, I tried the beta and kept having issues where it would launch to a black screen, wait, and then crash. Someone, somewhere, figured out that the game only runs properly if you have the text scaling at 100%; I had it at 150% because I was playing on a TV and the screen was unreadable at 100%. I have to wonder what Microsoft did with text scaling that it broke a DirectX game.
  - 5y ago
- kmeisthax 5y ago
  Apple and GNOME do this to avoid rounding errors when working in scalable layouts defined as screen-width percentages. Web browsers have accumulated all sorts of tricks and hacks to ensure that, say, floating four 25% width columns always adds up to the same width as a 100% column. This isn't a particular failing of CSS or the web - though CSS floats absolutely make this so much of a problem that browsers have to actually correct for this when users scale pages. Exposing a 1x design to non-integer scale factors fundamentally runs the risk of breaking it - you will get odd pixel gaps or misalignments which would not occur at integer scales, because the virtual pixel coordinates no longer line up with actual screen pixels.
  - kuschku 5y ago
    Qt has done that for many years, so has Android, so has Windows. Only macOS and Gnome don't, because they value single-pixel alignment errors more than the massive performance issues and reduced sharpness their solutions cause.
    - vetinari 5y ago
      And Qt after all those years does not work correctly in HiDPI. Not even on Windows. Unlike macOS and Gnome, which do.
      - kuschku 5y ago
        Gnome does NOT work correctly in HiDPI. I’ve got 3 systems with 1.5x scale, and Qt handles them perfectly fine (even with per-monitor separate scaling). While Gnome absolutely does not. Either I get absolutely unreadable tiny 1x, or I get absolutely unusable 2x with no space for anything. (That said, Qt on Windows handles per-screen scale factors very weirdly, especially with applications using pixel values)
        nextaccountic 5y ago
        In my screen, 1x and 2x are both inadequate, but I'm using Gnome on Wayland on 1.25 scaling right now. Gnome can do fractional scaling. You just need to configure it with a gsettings command: https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fractional-scaling.html https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fr... https://wiki.archlinux.org/title/HiDPI#Fractional_scaling https://wiki.archlinux.org/title/HiDPI#Fractional_scaling Or using gnome-tweaks. Then, on display settings, it should show up the new scaling configs. And, in Gnome it's very sharp, with zero blurring! It was somehow sharper than whatever KDE was doing when I tested it some months ago.
AzN1337c0d3r 5y ago
No he's right, it renders to a 2x resolution off screen with hidpi assets (2x resolution icons, double-size text, etc) and then does downsampling back to your screen resolution 2560x1600 for 13 inches, 2880x1800 for 15 inch, 3072x1092 for 16-inch MBPs.
csande17 5y ago
macOS does in fact do this kind of non-integer bitmap scaling. It's got nothing to do with what the GPU is capable of; Apple's UI framework can't do layout or text rendering at anything but "1x", "2x", or "3x" densities. This is also why the first Catalyst apps looked really blurry and bad on non-Retina displays; Apple applied a non-integer scale to the final rendered frames to work around UIKit not being able to draw the right size widgets.

chrismorgan 5y ago

I have always been utterly baffled by Apple’s approach to high DPI. They ship some of the best panels around, and then they kneecap them by using the most idiotic scaling scheme imaginable that guarantees that it’s worse than a low resolution panel for some tasks that want precision and uglier on things like single pixel lines which crop up a lot in e.g. web content, because pixel precision is impossible. Microsoft managed to do it right (though mixed-DPI took a couple of attempts), despite having no real power over developers. Meanwhile, Apple, who are in a position to sternly tell their developers to do it right or their software will break (and do so far more frequently than Microsoft), … caved and did it terribly? And do they even support real mixed DPI, or do they just fake it by rendering at the higher scale and downsampling to the other?

stephen_g 5y ago
This doesn't gel with my experience at all. Yes, past MacBooks weren't necessarily integer scaling (with this new display the default setting and what most people use will be though as far as I understand), and non-integer scaling is not ideal. But on my last two MacBooks at least the screen is visually plenty sharp, and looks way, way, better than the regular-DPI external monitors I still have (whether the external monitor is connected to the Mac or a Windows PC). And above all, my experience with Mac is that high-DPI has actually worked from the beginning, whereas on Windows I still have some apps that break if the scaling is not set to 100%! Even right at the start, old apps would look a bit blurry but would still at least be in the correct proportions on macOS, whereas with the Windows scaling a lot of stuff just wouldn't work!
- chrismorgan 5y ago
  I have no direct personal experience on high-DPI macOS. For Windows, I’ve only come across a couple of apps that claimed to support high DPI but severely mangled it, and they both got fixed before long; and a few others that had minor problems, e.g. opening windows at unscaled sizes so that you had to resize them, or rendering small icons. And to be sure there are various DPI-unaware apps, probably far more than on macOS (linked to why Apple was in the perfect position to implement and impose proper fractional scaling), but that’s not a serious problem either.