As a long-time developer against GTK (I started using it back in the 1.x days in the late 90s) this is really awesome to see. I enjoyed the side-by-side comparisons of the old vs new renderer, and especially the idea of homing in on particular letters ('T' and 'e') and extracting them, that really made the improvement clear. Cool stuff, and many thanks to the developers who keep pushing the GTK stack forwards.
against GTK? As in its philosophy? usage?
Maybe they meant programming against GTK, not being against it?
Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…
The real issue is that people want to be able to smoothly drag windows across monitors. This requires that each window be able to switch to a different DPI scaling when its "home" monitor changes. Something must also be done to deal with a single window being displayed across monitors with different resolution (which is what happens while dragging) though hardware scaling is probably acceptable there at some minor loss in quality - the "proper" alternative is to render natively at both resolutions, but applications might not natively support that.
> The idea is that we just place glyphs where the coordinates tell us, and if that is a fractional position somewhere between pixels, so be it, we can render the outline at that offset just fine. This approach works—if your output device has a high-enough resolution (anything above 240 dpi should be ok). So it just requires 6x more memory, GPU power and HDMI/DP bandwidth and prevents usage of large monitors ...
Don't high dpi screens consume more power as well?
I'm curious - when you were doing research into the mechanics of hinting options, did you stumble onto any relevant discussion around allowing custom pixel geometries to be defined, to enable hinting on modern OLED / WRBG displays? There's a good thread on the topic here[0], with some people referring to it as 'ClearType 2' on the MS side [1]. On the oss side I know FreeType theoretically supports this[2], but I can'…
It would be nice if monitors exposed info about subpixel geometry as part of their EDID data. An alternative would be to capture it in a hardware database.
The EDID standard does actually support that, but I don't think it ever saw much if any adoption.
Honestly I'd love it if Linux just implemented a solution similar to what Apple does, which is rendering everything at 2x and then downscaling it to screen's native resolution. (So my "3008x1692" on a 4K screen is actually rendered at 6016x3384). Modern GPUs are strong enough to do this without breaking a sweat, and the result is very crispy and functional. Fractional scaling could still exist as a fallback for older…
This is what GTK used to do. It's less battery efficient for an inherently less crisp option though. It also gets less seemingly crisp after rescale for for the much more common "slightly higher than normal dpi closer to 1080p" type monitors (e.g. the 125% in the article) you don't typically find in Apple setups.
Of course that's why subpixel rendering is all a bit moot on Apple devices. For a long time now they've just toggled the default font rendering to the equivalent of "none none" in this article and relying on the high quality screens the devices ship with/most users will plug in to make up for it.
Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…
Say your UI had a one "pixel" wide vertical line. At some point, resolution becomes high enough that you need to draw it two device pixels wide. What do you do at scales in-between?
Do apps start drawing their lines wider if the default font size goes up? When? Is it consistent system wide?
Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so…
The real issue is that people want to be able to smoothly drag windows across monitors. This requires that each window be able to switch to a different DPI scaling when its "home" monitor changes. Something must also be done to deal with a single window being displayed across monitors with different resolution (which is what happens while dragging) though hardware scaling is probably acceptable there at some minor lo…
My Macbook doesn't (always) drag smoothly across monitors. And I don't think anyone really complains about it?
As a long-time developer against GTK (I started using it back in the 1.x days in the late 90s) this is really awesome to see. I enjoyed the side-by-side comparisons of the old vs new renderer, and especially the idea of homing in on particular letters ('T' and 'e') and extracting them, that really made the improvement clear. Cool stuff, and many thanks to the developers who keep pushing the GTK stack forwards.
against GTK? As in its philosophy? usage?
He means utilizing GTK. In sweden its common to say "Utveckla mot xxx" Develop against, when talking about using a framework or library. I bet they say the same thing i Other germanic languages.