61–70 of 70 posts
I'm very excited for the multi gesture track pad support. It's such a small change but I just haven't been able to find good support for this outside of Mac OS. I'm tempted to install this version the second they hit their first release candidate for that feature alone.
https://neosmart.net/blog/2020/multi-touch-gestures-on-linux...
Earlier quoted context omitted.
> I think it’s a fair philosophical choice. Fractional scaling is really hard. macOS doesn’t bother, choosing instead to render at an integer scale factor and downsample. Doing something similar on Linux would be hard, for mostly historical reasons. What macOS does is the cleanest and most correct way to fractionally scale in my book. Why would it be hard on Linux? You just blit the buffer at whatever resolution you…
In Wayland this is simple. In Xorg it is not because the X protocol contains no knowledge of what scaling factor your app is rendering at. The server doesn’t know about DPI scaling. You can’t just make things “appear” as if they’re a different scale factor; X apps get real pixel coordinates in their events, directly from the X server. The Wayland compositor is aware of what DPI every surface is in a given frame exact…
It's ironic, I think, you say Apple is an idealistic company, but they have implemented a very simple and pragmatic approach, and with great results.
While here we're discussing why Linux can't do the same due to a dozen self-imposed restrictions that don't matter in practice. The concept of (non-fractional) logical pixels can be implemented very neatly into any rendering subsystem without this affecting the concept of pixels, or events, etc. Seems no one can see the forest for the trees in this case.
Earlier quoted context omitted.
In Wayland this is simple. In Xorg it is not because the X protocol contains no knowledge of what scaling factor your app is rendering at. The server doesn’t know about DPI scaling. You can’t just make things “appear” as if they’re a different scale factor; X apps get real pixel coordinates in their events, directly from the X server. The Wayland compositor is aware of what DPI every surface is in a given frame exact…
Fractional scaling is mostly needed on High DPI displays. High DPI displays also happens to be the case where you don't need subpixel AA, nor you need native FS rendering. Even for East Asian languages. It's ironic, I think, you say Apple is an idealistic company, but they have implemented a very simple and pragmatic approach, and with great results. While here we're discussing why Linux can't do the same due to a do…
2x scale displays certainly make East Asian text readable, but rendering 2x and downscaling to 1.5x will do a lot of damage to the legibility. It’s far from ideal.
> It's ironic, I think, you say Apple is an idealistic company, but they have implemented a very simple and pragmatic approach, and with great results.
When they first implemented it, it shipped on displays that could only handle 1x scaling for a very long time. The first “Retina” Macbook is from 2012, while macOS is from 2001. I have an iBook G4 sitting next to me. It’s a nice piece of hardware, but yes, text is blurry. Apple is “idealistic” in that they favored elegant engineering over practicality. Not everything Apple has ever done embodies this, but they definitely try to change the status quo rather than make the most of it, and this is surely no different.
I didn’t say it as necessarily a jab, but it had its tradeoff. It’s a distinctly Apple move.
> While here we're discussing why Linux can't do the same due to a dozen self-imposed restrictions that don't matter in practice. The concept of (non-fractional) logical pixels can be implemented very neatly into any rendering subsystem without this affecting the concept of pixels, or events, etc. Seems no one can see the forest for the trees in this case.
The self-imposed restrictions you refer to are issues with the design of the Linux graphics stack. Like I said, the X11 protocol does not afford the X server any awareness to the scaling an application renders at. The deeper you dig the clearer it is that it simply couldn’t be fixed. In the X11 world, screen coordinates are exposed to all clients. In the Wayland world, clients only use surface-relative coordinates. This might sound like an unimportant distinction, but when you are trying to implement DPI virtualization, the API matters. If applications running at different scale factors suddenly have their drop down and context menus appearing all across the screen, that’s not a good experience.
So why is X11 like this? Well, it’s ridiculously old. The X protocol has changed and evolved a fair bit, but it’s so old that its lineage predates the very first Mac altogether. Xorg has improved plenty in the last 20 years, but the protocols have been largely frozen for quite a while, with some minor exceptions. Trying to fix these issues now, 40 years down the road, is a losing battle. It would be possible to try to pull a Microsoft, invent and implement a new DPI virtualization layer. But it’s just not that simple. Xorg does not have a builtin compositor, and it does not force you to use compositing. From the server PoV, there’s no obvious place to scale surfaces. There aren't even "surfaces."
The list goes on. So if it’s so old and problematic, why didn’t they try to fix or replace it? Well, it turns out they have. It’s called Wayland. It’s not new; it’s been cooking since 2007. Wayland provides a global compositor that is aware of the scaling factor of surfaces and old X11 apps are DPI-virtualized by virtue of the way Xwayland works.
So why isn’t Wayland everywhere? Because open source developers can’t will it into existence. They have to push things forward incrementally. The Linux desktop is not exactly the best funded thing in existence. Canonical decided to try to pursue their own display standard called Mir instead of collaborating on Wayland, so their resources were not going into it. Meanwhile, semi-political squabbles with NVIDIA and the Linux kernel developers has lead the proprietary NVIDIA drivers to be very slow to support Wayland. NVIDIA tried to forge a path around the unified buffer management APIs used by every other graphics vendor and proposed EGLStream, which ultimately hasn’t worked out and they are now pursuing a better path forward.
The lesson here is you can’t say “why didn’t they just do the obvious thing? It’s sad everyone is too stupid to understand this.” Nobody doesn’t get how to implement DPI virtualization. But in 1984, display scaling wasn’t on the top of everyone’s mind. It wasn’t in the early 2000’s either. So it’s not surprising that the decades long legacy of X has left it hard to handle scaling.
It's worth adding on here: The reason they did not simply try to use the existing X drivers is because that was an equally bad thorn in their side fraught with plenty of peril. But let's please not get into that. I am not an expert, and when I dug into it, it felt like enough yak shaving to last a life time.
In other words:
Tl;dr: it’s hard to do under Linux for historical reasons.
Earlier quoted context omitted.
Fractional scaling is mostly needed on High DPI displays. High DPI displays also happens to be the case where you don't need subpixel AA, nor you need native FS rendering. Even for East Asian languages. It's ironic, I think, you say Apple is an idealistic company, but they have implemented a very simple and pragmatic approach, and with great results. While here we're discussing why Linux can't do the same due to a do…
> Fractional scaling is mostly needed on High DPI displays. High DPI displays also happens to be the case where you don't need subpixel AA, nor you need native FS rendering. Even for East Asian languages. 2x scale displays certainly make East Asian text readable, but rendering 2x and downscaling to 1.5x will do a lot of damage to the legibility. It’s far from ideal. > It's ironic, I think, you say Apple is an idealis…
I'm typing this on a MacBook with scaled display and legibility is just fine. Asian scripts look fine, too. iPhones also use a scaled output (most recent models all do, there's no match between physical pixel and GPU pixel at all anymore on OLED, and there's no match between GPU and logical pixel either). You'll never hear customers in Japan or China complain about poor legibility.
That's the difference between theory and practice. If you try it, you realize there's no problem. Otherwise I'm sure we can keep writing about how bad it's in theory all day.
> I have an iBook G4 sitting next to me. It’s a nice piece of hardware, but yes, text is blurry.
You're talking about an iBook that 1) isn't high DPI 2) using OSX which isn't scaled (fractionally or in any way at all).
I'm sorry but your iBook is irrelevant to the discussion. We're not discussing here legacy text AA on legacy low DPI display. None of this matters.
Earlier quoted context omitted.
> Fractional scaling is mostly needed on High DPI displays. High DPI displays also happens to be the case where you don't need subpixel AA, nor you need native FS rendering. Even for East Asian languages. 2x scale displays certainly make East Asian text readable, but rendering 2x and downscaling to 1.5x will do a lot of damage to the legibility. It’s far from ideal. > It's ironic, I think, you say Apple is an idealis…
> 2x scale displays certainly make East Asian text readable, but rendering 2x and downscaling to 1.5x will do a lot of damage to the legibility. It’s far from ideal. I'm typing this on a MacBook with scaled display and legibility is just fine. Asian scripts look fine, too. iPhones also use a scaled output (most recent models all do, there's no match between physical pixel and GPU pixel at all anymore on OLED, and the…
>That's the difference between theory and practice. If you try it, you realize there's no problem. Otherwise I'm sure we can keep writing about how bad it's in theory all day.
I do not appreciate the way you are treating me as if I clearly do not have any experience or knowledge on the subject matter. I in fact use an iPhone and have owned multiple Mac computers, including my M1 Mac Mini. I also studied Japanese in college and font rendering was always a kind of issue.
Comparing Linux and macOS is not too interesting since Linux actually is closer to macOS in many regards with font rendering. Instead, it would be instructive to first compare Windows 10 to macOS (Big Sur).
https://files.catbox.moe/cho5iw.png
This comparison shows the default fonts in macOS and Windows 10 rendering the word 「醤油」. macOS Text Edit is on the left, and Windows 10 Notepad is on the right. I set the font size to 10pt on Windows to help make it a more even comparison; Windows defaults to 12pt which makes 1x plenty legible. However, in a head-to-head comparison at a similar font size, 1x is not terribly legible here on either side. Still, at 1.5x you can see a clear difference in legibility already. This is with a common word that is mildly complex, but still not nearly the worst case scenario for typography. And yet, some of the features are quite difficult to distinguish. It's good enough, but it's not great. The Windows typography here is ugly, but practical.
What if macOS could scale 1.5x natively? Well, the comparison would look like this:
https://files.catbox.moe/hiyvr6.png
On the left is 12pt at 1x, and on the right is 18pt at 1x. At first glance it does look similar, and neither is ideal. However, this is still a noticeable improvement. The two strokes near the bottom of the left kanji are now distinguishable with the human eye, and it is generally less blurry. This is without the advantage of hinting or subpixel AA, which should make it even less blurry and increase the horizontal spatial resolution enough to make more features easily distinguishable. And this is still not a worst case example. It’s an example of something common.
By the way, regarding iPhones. I have an iPhone XS. The iPhone XS has a DPI of 458! That is insane. The monitor I'm currently using, by comparison, has a DPI of around 110. So yes, you can get away with quite a lot on an iPhone XS without any noticeable artifacts or blurriness. But that's not realistic. Laptops and phones are different devices with different hardware and different distances that we view them at. OLED displays on computers are still the exception.
> You're talking about an iBook that 1) isn't high DPI 2) using OSX which isn't scaled (fractionally or in any way at all).
> I'm sorry but your iBook is irrelevant to the discussion. We're not discussing here legacy text AA on legacy low DPI display. None of this matters.
I don't know what to tell you, I was trying to illustrate the pitfalls of Apple's early choice to not integrate techniques like hinting and subpixel anti-aliasing into their font rendering. It's not like the font rendering looks meaningfully different on an iBook G4 than it does today, it's that the screens have gotten higher resolution. They waited it out. If you want to talk about impractical decisions, the 10 year stretch when Apple laptops had blurry fonts and no HiDPI displays is certainly relevant to the discussion.
Also, Linux still needs to support 1x rendering well. It does not have the luxury of choosing the hardware it runs on.
I like elmentary. It's pretty, works well, etc. One thing that did irritate me was when I had to install something that wasn't "default." A gnome or QT application, and it looked to fugly. Just didn't work.
I with these guys the best. I think what they are doing is really cool, and I admire all the work they've done in vala and what not.
Elementary OS has truly come so far. I still remember the old days where it started as a Gtk theme and how excited I was back in early 2010s to try out the beta versions of Luna. Unfortunately haven't used it since I bought a MacBook, but I truly appreciate the effort by Elementary team to provide a well thought out aesthetically pleasing linux distribution.
I'm honestly always confused as to what makes Elementary (or Mac for that matter), so much more pleasing than the much maligned GNOME? I'd like to understand because these discussions which often include "I'd use Linux but awful desktop" always leave me feeling like people are tapped in to a dimension I'm not privy to.
10 years later I'm on vanilla GNOME and I think it's amazing. Truly perfected.
Earlier quoted context omitted.
> 2x scale displays certainly make East Asian text readable, but rendering 2x and downscaling to 1.5x will do a lot of damage to the legibility. It’s far from ideal. I'm typing this on a MacBook with scaled display and legibility is just fine. Asian scripts look fine, too. iPhones also use a scaled output (most recent models all do, there's no match between physical pixel and GPU pixel at all anymore on OLED, and the…
>I'm typing this on a MacBook with scaled display and legibility is just fine. Asian scripts look fine, too. iPhones also use a scaled output (most recent models all do, there's no match between physical pixel and GPU pixel at all anymore on OLED, and there's no match between GPU and logical pixel either). You'll never hear customers in Japan or China complain about poor legibility. >That's the difference between the…
Supporting FS using the macOS algorithm doesn't affect 1:1 rendering at all. You can enable subpixel AA when rendering at non-fractional scale, and you can disable it when you do fractional scale.
Windows 10 already does this per control i.e. when you render a control in RGBA it disables subpixel AA, otherwise it supports it. In this case what I propose is vastly simpler: do it per desktop, or even per X server instance.
It's literally an afternoon project, and let people pick their settings.
Anyway none of this matters, because Linux on the desktop doesn't matter either (yet). And with that attitude honestly it'll never matter.
As a last note, you can do subpixel AA with the macOS algorithm. It'll be more performance intensive as it'll be a custom shader to scale this way, but it's mathematically 100% doable. I just don't think it's worth the bother.
Earlier quoted context omitted.
>I'm typing this on a MacBook with scaled display and legibility is just fine. Asian scripts look fine, too. iPhones also use a scaled output (most recent models all do, there's no match between physical pixel and GPU pixel at all anymore on OLED, and there's no match between GPU and logical pixel either). You'll never hear customers in Japan or China complain about poor legibility. >That's the difference between the…
I'm sorry the conversation tone is changing, I didn't do this intentionally. But there are few things that logically don't connect for me here. Supporting FS using the macOS algorithm doesn't affect 1:1 rendering at all. You can enable subpixel AA when rendering at non-fractional scale, and you can disable it when you do fractional scale. Windows 10 already does this per control i.e. when you render a control in RGBA…
And yeah, UI toolkits could switch off hinting and subpixel AA at 2x. I acknowledge that this would be logical anyways, since subpixel AA is not very useful at 2x.
But honestly, as far as Apple typography goes, it’s all beside the point. This was in a thread where I was initially trying to demonstrate that doing it in Linux is hard for historical reasons. I believe I made that point. As for will it ever be done? Well, like I said, it has been done. Wayland supports what you are describing and more just fine, right now, and it works very well. (Full disclosure that most programs will actually just use fractional scale, but you can also round up to the next integral and the compositor will downsample as you would hope.) The actual hard problem is getting Wayland working for everyone, on their hardware and with their software. Progress is being made every year, but it’s been a long road. Until then, I just think it would make more sense for Elementary OS to work on more tractable problems with the Linux desktop.
Earlier quoted context omitted.
More recent threads about fractional scaling on elementary include the comment "[fractional scaling] is blocked by moving to Wayland". I can understand the developers not wanting to implement a FS hack that will likely be replaced soon anyway, when the project priority is supposed to be UX innovation. I can also understand delaying the move to Wayland until it meets the standards for stability. But in the meantime it…
FS isn't hard to implement, you scale by integer factor and scale down the buffer to fit the screen. This is literally how masOS does it. And they've basically pioneered the concept of scaling for high DPI screen when they introduce Retina.
