Submit Login Macos Mojave Removes Subpixel Anti-Aliasing, Making
Total Page:16
File Type:pdf, Size:1020Kb
Hacker News new | comments | show | ask | jobs | submit login MacOS Mojave removes subpixel anti-aliasing, making non-retina displays blurry (reddit.com) 215 points by laurentdc 6 hours ago | hide | past | web | favorite | 188 comments add comment ridiculous_fish 2 hours ago [-] ex-MacOS SWE here. Subpixel antialiasing is obnoxious to implement. It requires threading physical pixel geometry up through multiple graphics layers, geometry which is screen-dependent (think multi-monitor). It multiplies your glyph caches: glyph * subpixel offset. It requires knowing your foreground and background colors at render time, which is an unnatural requirement when you want to do GPU-accelerated compositing. There's tons of ways to fall off of the subpixel antialiased quality path, and there's weird graphical artifacts when switching from static to animated text, or the other way. What a pain! Nevertheless there's no denying that subpixel-AA text looks better on 1x displays. Everyone notices when it's not working, and macOS will look worse without it (on 1x displays). reply omarforgotpwd 0 minutes ago [-] "Listen guys the code for this is a mess. Can you just buy the new Macbook?" (love my latest gen Macbook Pro, but this is the classic problem with Apple's approach to product design) reply captainmuon 1 hour ago [-] Personally, I think that is moving in the wrong direction. This is the reason text looks bad on transformed HTML elements in browsers, or when you click a button on Windows and it tilts slightly. Text rendering should be aware of the (sub)pixels, even post-transform. While we're at it, this can apply to vector art, too. If we ever want to have a hope of computers looking like, e.g. this Microsoft fluent design mockup [1], which is clearly window-based, but the windows are tilted slightly and shaded giving it a physical appearance, we'd have to go in that direction. If we stay in the model where everything is a texture that gets composited, the only thing we can do is to use higher resolution / retina display. Also, one thing I've never seen discussed are virtual displays inside a VR world. The VR headset has plenty of pixels, but you can't simulate a full HD screen at a few feet distance, let alone a retina screen. [1] https://cdn0.tnwcdn.com/wp-content/blogs.dir/1/files/2017/05... reply akvadrako 1 minute ago [-] Obviously the right direction is replacing sub-pixels with pixels. Maybe you meant this is premature? reply SCdF 47 minutes ago [-] > Subpixel antialiasing is obnoxious to implement Totally, but > there's no denying that subpixel-AA text looks better on 1x displays. I get that it's hard, but at the end of the day what users are going to notice is, when they dock their laptop at work, their display is going to look like fuzzy crap. Maybe most people won't notice? It's hard to tell without seeing a side-by-side comparison. reply eloisant 34 minutes ago [-] I guess Apple just wants everyone to buy retina displays, and don't care about people using what they believe is "legacy" hardware. reply ksec 3 minutes ago [-] This wouldn't be a problem, if 1) They had Retina MacBook Air 2) They actually have a Monitor Line, that is Retina+ Display, Super great colour accuracy etc. For 1st point Apple doesn't seems to care, and 2nd point, Apple should at least have a list of Monitor that work best or up to their "Standards". Or on sale at Apple Store. These attention to details, in its ecosystem weren't as obvious when Steve were here. But recently they have started to show cracks everywhere. reply akvadrako 0 minutes ago [-] This is a good indication they will remove the Air from the lineup this fall and replace it with a lower-end MacBook. trumpeta 2 hours ago [-] I have a 2015 rMBP with nVidia 750m and recently I switched from Apple Cinema Display to a 4k screen. At any of the graphical modes between the full 2x retina and 1x the whole OS gets extremely sluggish to the point of unusable. Some people from Jetbrains have looked into it and concluded it was the font rendering in IDEA bringing down the entire system. Do you think this change can improve this? Because it certainly sounds like it. reply Arkanta 56 minutes ago [-] Sorry for the rant, but given the price of the JetBrains Toolbox, it infuriates me that they've been giving us HDPI users the middle finger for a couple of years now. First of all, switching to grayscale helps A LOT. mojave does this system wide, but the JVM (or IntelliJ, I don't really remember) has its own font rendering system, so you need to change that in IntelliJ directly. I was hurt terribly by this issue. My problems have been solved by three things: - IDEA update that reworks the statusbar undertermined progress bar, which maxed my cpu just for a dumb anymation - Going from an iGPU to dGPU mac (you seem to have one, so congrats, it would be way worse with only your iGPU) - Using an experimental JVM from this thread: https://youtrack.jetbrains.com/issue/IDEA-144261 That said, JetBrains messed up with their 2018.1 release again. I'm mostly using Android studio, which lags behind IntelliJ's versions. 3.1 merged the stupid progressbar fix, but I'm not looking forward when 3.2 hits stable, with 2018.1 merged in. Bottom line is that there are multiple factors in JetBrain's custom OpenGL UI inefficiencies combined with Oracle's JVM bugs/inefficiencies that takes down the whole system, but it's ultimately not only a font smoothing issue. JetBrains doesn't really care, or at least doesn't show that they care. They first said "we don't notice that", and then released some JVM patches in the comments of an issue. Of course, Oracle also shares part of the blame: none of this would have happened had they kept Apple's JVM Quartz support. reply davnn 2 hours ago [-] > Subpixel antialiasing is obnoxious to implement. Isn't it completely abstracted away from 99%+ of macOS development? reply jacobolus 2 hours ago [-] Yes, but if it dramatically increases complexity for all the lower levels of the rendering stack, it ends up creating extra work for those OS/framework developers, requiring separate versions of the code targeting different displays which must be maintained separately with different sets of bugs in each, preventing them from making large-scale architectural changes they want to make, restricting some types of significant optimizations, etc. reply sova 1 hour ago [-] Yeah but isn't it already a solved problem with 1x monitors? Who is implementing things multiple times for no reason? I'm glad in the future it will be easier for Apple because they just won't hire devs to do that part then, but does this imply that 1x monitors will simply look inferior no matter what is done with newer versions of OSX+? reply systoll 9 minutes ago [-] There's a broader change that is an improvement to the abstraction devs work with, which simplifies coding and results in more GPU acceleration. Essentially, this article: http://darknoon.com/2011/02/07/mac-ui-in-the-age-of-ios/ will be obsolete. If it's possible to realise those benefits while retaining subpixel antialiasing, it would entail a complete reimplementation. On the other side of things -- Light-on-dark subpixel antialiasing has always been a little wonky, and Apple disables it in most dark UIs. Without significant changes, dark mode would've been greyscale either way, reply rbanffy 1 hour ago [-] This complexity is why we can't have windows that spread between 1x and 2x monitors since the introduction of Retina displays. Ideally everything should be rendered (and cached) to the maximum resolution available (minimum trace widths considered) and then downsampled to the specific screens with subpixel data applied, but that's a lot of processing to do and battery life would suffer. reply brigade 38 minutes ago [-] Eh? Before Yosemite was released in 2014, one window could span between a 1x and 2x monitor. I forget if it was always rendered at 1x, or if it was rendered at 2x and scaled for the 1x, but yeah it looked like crap on one or the other. Actually I think it switched depending on which monitor had more of the window? But they only eliminated windows spanning across multiple monitors when they made spaces per-display. reply jacobolus 1 hour ago [-] It’s already a solved problem if you want to keep using the software you already wrote, and never do anything different. (Nobody is stopping people from running OS X 10.13 indefinitely on their 1x displays.) If you want to rearchitect your whole text / vector graphics rendering pipeline to take proper advantage of GPUs, then you are going to be much happier with your life if you don’t have to double your work to support legacy hardware. I would love to see Apple implement this kind of thing http://w3.impa.br/~diego/projects/GanEtAl14/ reply tobr 2 hours ago [-] This and the document @gnachman posted has me intrigued. Are you saying that subpixel AA is not just like a multichannel mask? I would expect the amount of R/G/B foreground and background color for a given pixel to be the same regardless of what those colors actually are? reply jgh 1 hour ago [-] (note I haven't worked on subpixel AA for font rendering, but have for something different) the amount of color you apply to each subpixel has different levels of intensity depending on how deeply into the pixel the shape goes, so you would need to blend with whatever is behind/in front of it.