[jcollie]

Adds a comptime function to enable conditional compilation against different GTK versions that have added new API calls in newer versions of GTK.

Use this function to get fractional scaling information for GTK surfaces, which is only available with GTK 4.12+.

[mitchellh]

Will this fix #1938?

[jcollie]

Possibly. I'll try this on my laptop that I have hooked up to a 4K screen.

[gpanders]

Can't Ghostty be compiled against one version of GTK but link against another (older) version? I thought that comptime version checking wouldn't work for this reason.

FYI I looked into this same problem several months ago now, also for the fractional scaling issues. I still have the commit on my fork: gpanders@df52606

The issue I ran into is that even if you use the scale factor of 1.5 to scale cells on Ghostty's side, the apparent cell size (what is actually rendered) was still incorrect. My understanding at the time is that this was happening because the compositor is doing the downscaling from 2x to 1.5x when fractional scaling is enabled, so Ghostty must still render at a 2x scale to the OpenGL surface. There was a Discord discussion about this here: https://discord.com/channels/1005603569187160125/1005603569711452192/1193994623702544404

Maybe this has changed in newer versions of GTK though. I haven't looked at it since then.

[jcollie]

You can compile against an older but runtime link against a newer version. I don't think that the reverse is possible, even if you avoid calling any GTK APIs that aren't present in the older version.

[jcollie]

OK, I tried this patch on my laptop with an external 4K screen and I couldn't see a discernible difference between Ghostty and Gnome Console - screen was set to 275% scaling. I'm not the pickiest when it comes to these things though, I'm pretty tolerant of "good enough". You'll definitely need to compile against GTK 4.12 (I was using 4.14). The default Ghostty Nix package is still compiling against GTK 4.10. (Ghostty on the left and Gnome Console on the right).

[tristan957]

Can you just use https://docs.gtk.org/gtk4/func.check_version.html? Alternatively there is the macro form: https://docs.gtk.org/gtk4/func.CHECK_VERSION.html. Not sure if comptime can handle that.

[jcollie]

Looking at the source for gtk_check_version that looks more like a runtime check and would possibly include some string comparison. There's also usage of GTK_BINARY_AGE whatever that is.

Looking at the source for GTK_CHECK_VERSION I think it might work but I don't think that there's really one reason to prefer one over the other. Zig can get weird with C macros from time to time so I prefer the Zig version personally.

[mitchellh]

It's unclear to me whether this PR actually solves any real problems. I'm not saying that to be rude, I'm saying it in a way of genuine curiosity: is this PR worth merging? does it work despite shortcomings? is it the right approach? None are entirely clear given the discourse.

[jcollie]

It's unclear to me whether this PR actually solves any real problems. I'm not saying that to be rude, I'm saying it in a way of genuine curiosity: is this PR worth merging? does it work despite shortcomings? is it the right approach? None are entirely clear given the discourse.

I think that the biggest win is that fractional scaling will work better if you compile against GTK 4.12 or newer since that has the API calls for non-integer scaling. There likely are other scenarios where the ability to take advantage of newer API calls in a backwards-compatible manner. There are a lot of LTS distros that are still supported that are still on GTK 4.10 so I don't think that we want to eliminate compatibility with GTK 4.10 yet.

libadwaita faces a similar issue in that the version shipped with some LTS distros lack some widgets that we'd like to use.

FWIW I've been daily driving this patch since I wrote it and I have had no troubles that I can attribute to this patch. I can't really comment on how effective the fractional scaling is because the displays that I normally use are all set for 100% scaling.

[tristan957]

I personally don't think the project should be held back by LTS distros.

[gpanders]

I think that the biggest win is that fractional scaling will work better if you compile against GTK 4.12 or newer since that has the API calls for non-integer scaling

Is this actually the case? See my earlier comment above, when I tried using these APIs in Ghostty it did not work as expected (the issue being that Ghostty still needs to render at 2x scale even when fractional scaling is enabled, so the fractional scaling APIs are not actually helpful). But I haven’t looked at this in a few months so it’s possible the situation with some compositors have changed.

EDIT: Ah just saw your comment here, so perhaps GTK handles this properly now. Alas I don’t have my 4K monitor anymore to test with 1.5x scaling myself :(

[jcollie]

I personally don't think the project should be held back by LTS distros.

We go to some lengths to support older macOS versions (macOS 12 was released on October 25, 2020) and in #2083 some conditional compilation to take advantage of some macOS 13+ APIs was added.

So I'd say that precedent has been set that older versions need to be supported (within reason, mainly the presence of upstream support) and that conditional compilation can be used to take advantage of newer APIs.

[mitchellh]

We go to some lengths to support older macOS versions (macOS 12 was released on October 25, 2020) and in #2083 some conditional compilation to take advantage of some macOS 13+ APIs was added.

So I'd say that precedent has been set that older versions need to be supported (within reason, mainly the presence of upstream support) and that conditional compilation can be used to take advantage of newer APIs.

Note that in #2083 it's not conditional compilation... it's a runtime conditional. We only use conditional compilation on the macOS side for platforms (iOS vs macOS).

[mitchellh]

Fwiw I don't see much downside to merging this. Even if it only works in certain cases it's not really any additional maintenance burden at all and I don't see it making anything worse (famous last words). I'll try to merge this later.

[tristan957]

This broke fractional scaling for me. I bisected to this commit. I can now barely see the text in the terminal.

[mitchellh]

I’ll revert it. There’s no absolutely known case this fixed and we now have one case it definitely broke.

[mitchellh]

Reverted

[jcollie]

What version of GTK? I use it with 4.14 and I've not seen any problems (granted I don't usually use fractional scaling). Perhaps it's broken in 4.12.

[tristan957]

4.14 with 125% scaling on GNOME.

[tristan957]

After asking the GTK Matrix room, this PR would return 1.25 for 125% scaling in >=4.12 and 2 for <4.12, which would explain the much smaller text.

[mitchellh]

After asking the GTK Matrix room, this PR would return 1.25 for 125% scaling in >=4.12 and 2 for <4.12, which would explain the much smaller text.

Does this mean the PR is correct then and your font size just needs to be bumped up since you were making it smaller for < 4.12?

[tristan957]

With the same font + font size in Ghostty and Ptyxis (VTE), they show up differently on my screen with this PR applied. Without this PR, they are the same.

[mitchellh]

With the same font + font size in Ghostty and Ptyxis (VTE), they show up differently on my screen with this PR applied. Without this PR, they are the same.

Does Ptyxis support fractional scaling?

[tristan957]

I'm asking, but there is nowhere on this system where I would need a font size so drastically different. I use the same font size for GtkTextView and GtkSourceView, and it works fine. But then I guess, I don't know the answer to "Do those widgets support fractional scaling?".

[mitchellh]

Right. A font size "14" at 1x vs 2x scaling is dramatically different (double, really!). So even 125% vs 200% is significantly different. If two apps use different scales, you're going to see very different sizing.

[tristan957]

Here is a screenshot from #gnome-hackers. I don't know how to interpret it.

[mitchellh]

I also don't understand it. lol.

[tristan957]

At this point, all I can say is that my terminal was readable at 100% scaling on one laptop and 125% scaling on the other laptop prior to this commit. I'm not sure if I'm in the wrong or something related to how ghostty uses the output of getContentScale() is wrong, but I wouldn't love if my configs diverged between laptops since I track it in Git.

[tristan957]

I don't know if this illuminates anything: "GTK very much treats a 10pt font @ 150% scale the same as a 15pt font at 100% scale"

[mitchellh]

I'm not exactly sure how they mean, since the calculation from points to pixels is:

px = pt * (dpi / 72)

Content scale affects DPI. Your pixel size for an equivalent point size can't remain constant across DPI changes.

[tristan957]

Are foot or alacritty fractional scaling aware? Happy to test

[mitchellh]

It appears so, and they have a great README section on DPI and font size, noting how scaling affects font size: https://codeberg.org/dnkl/foot#dpi-and-font-size

[gpanders]

GTK 4.12 includes gdk_surface_get_scale which returns a fractional scale (e.g. 1.25) but this results in a bug because 4.12 still implements fractional scaling by rendering to a larger surface and downscaling in the compositor (this is my loose understanding anyway). This means that on GTK 4.12 Ghostty should still render at a 2x scale, but using gdk_surface_get_scale makes Ghostty render at 1.25 in this case, which results in a smaller font size.

GTK 4.14 properly implements fractional scaling so this is not the case. This is exactly the issue I ran into when I looked into this (as I've mentioned a few times in this thread already). So the check for GTK 4.12 is insufficient, it should be checking for GTK 4.14 (which provides both gdk_surface_get_scale as well as properly implements fractional scaling).

Though @tristan957 mentioned they are using 4.14 here, so I might still be missing something. But in any case, I feel fairly confident in saying that using gdk_surface_get_scale will for sure not work on 4.12 (from my own testing).

[tristan957]

Another weird data point, this PR also breaks window sizing for me. I have window-width = 80, and ghostty shows a width larger than that, at least according to the height/width overlay.

[tristan957]

Foot with the following config has the expected working font size:

font=Cascadia Mono PL:size=10

[jcollie]

Another weird data point, this PR also breaks window sizing for me. I have window-width = 80, and ghostty shows a width larger than that, at least according to the height/width overlay.

Perhaps gtk_window_set_default_size isn't supposed to take fractional scaling into account?

[tristan957]

I've at least never heard of anyone doing that.