41–50 of 198 posts
Earlier quoted context omitted.
> E.g. it could alternate between 1 black and 1 white pixel in the physical buffer or it could sometimes make two adjacent pixels the same color. This is a very odd definition of "no blur".
It works in chromium without anything I'd call blur. Here it is at 175% scale: https://i.ibb.co/DtKm69d/image.png
Big fan of mixing & matching not just on hardware I see
"Free Software Foundation position on firmware ... is that if a device has ... firmware ... in a form that users can’t modify, then the system as a whole is not free software. This is technically correct but doesn’t logically imply that the right strategy for advancing free software is to forbid firmware blobs" It may not be the convenient thing for novice users, but it is an important strategy to "dogfood" fully-fre…
> Privileging principle over praxis is generally a losing strategy. Unfortunately it’s also Stallman’s — and thus sadly by extension the FSF’s — entire shtick.
GUIX is much much more restricted.
I've been intrigued by Guix for a while; mainly because I like the idea of Nix but was very turned off by its language, when I was exposed to it through a job I had. One thing I liked about Nix was that it was possible to use its packaging and tools without actually using the NixOS. An old employer used this instead of Docker for managing build distribution. Can the Guix stuff be used the same way?
I've been intrigued by Guix for a while; mainly because I like the idea of Nix but was very turned off by its language, when I was exposed to it through a job I had. One thing I liked about Nix was that it was possible to use its packaging and tools without actually using the NixOS. An old employer used this instead of Docker for managing build distribution. Can the Guix stuff be used the same way?
Earlier quoted context omitted.
> E.g. it could alternate between 1 black and 1 white pixel in the physical buffer or it could sometimes make two adjacent pixels the same color. This is a very odd definition of "no blur".
It works in chromium without anything I'd call blur. Here it is at 175% scale: https://i.ibb.co/DtKm69d/image.png
Earlier quoted context omitted.
It works in chromium without anything I'd call blur. Here it is at 175% scale: https://i.ibb.co/DtKm69d/image.png
Does the scaling change the kerning of the letters? This looks horrific! (and, yes, blurry, or "antialiased" as is custom to name it).
My kingdom for Wayland fractional scaling that doesn’t make my apps blurry. It makes the feature a complete nonstarter for me.
Fractional scaling, by definition, will make stuff blurry. Clean bitmap graphics and fractional scaling are incompatible requirements. Proof: consider a pattern of alternating black and white pixels: 0, 255, 0, 255, 0, 255, etc. This pattern cannot be scaled to a non-integer factor without introducing gray colors (i.e., by blurring-out the pattern). If your app produces this pattern, then fractional scaling will blur…
You cannot scale things to non-integer amounts without incurring some damage.
Blurry/fuzzyness, ringing, screen door effect, etc, you cannot avoid these no matter how smart your scaling algorithm is as long as you're upscaling it to something inbetween 100% and 200%. Nyquist-Shannon is a bitch.
Wayland made a decision way back that non-scaling apps can only be integer scaled to avoid this defect. This was the correct decision, objectively. Unfortunately, people still choose to own monitors that have weird resolutions that do not approximate 96dpi after integer scaling.
Thankfully, 200% dpi screens (ex: 3840x2160 in 24", where 24" are normally 1080p) are starting to become the norm, so someday this problem will go away: you will always be scaling at least 200%, making non-integer scaling artifacts a lot less visible.
Also, I think the parent comment that enriquto replied to might be confused and is merely asking for nearest neighbor scaling. This is not part of Wayland (which is just a protocol), and is managed entirely by the WM being used. Given Wayland is trying to enforce integer scaling, WMs allowing choosing nearest neighbor when integer scaling would be preferable in many cases.
Earlier quoted context omitted.
Fractional scaling works perfectly well on Xorg Linux and Windows, but looks blurry on Wayland Linux. Maybe it's not micrometer-scale crisp, but I can't see that. Text on Wayland is very visibly blurred. And it's not just text, but UI controls too. It looks like Wayland just renders the lower integer scale factor and then stretches the resulting bitmap image. That's bullshit.
Doesn't macOS do it the other way, rendering at the next highest integer scale factor and then downscaling to fit the display? If you can't render fractional factors natively for tech debt reasons then that's the least bad way to do it.
However, Wayland does not prescribe any method for non-integer scaling. Any Wayland WM could choose to do the same thing, and it would be hardware accelerated essentially for free.
Both X11 and Wayland WMs typically don't use this trick, and neither does Windows.