GTK+ is responsible for dealing with scaling, moving there.

GTK3 has built-in support for integer scaling and should use it automatically if you set Windows up to scale everything by 200%, 300%, 400% etc. There is no support for fractional scaling however.

Have you tried to change Windows DPI compatibility settings for gedit.exe (context menu, properties, compatibility, override DPI scaling)? You should be able to prevent Windows from scaling it to 150% the way it scales everything else.

After that you might be able to increase all font sizes by setting the GDK_DPI_SCALE to a fractional value > 1. All pixel-objects will still be small-ish, but anything with text will be bigger. Alternatively, enforce GDK_SCALE=2 to make all UI 2x larger, and then dial down GDK_DPI_SCALE to a value < 1 to at least reduce textual UI parts somewhat.

There are probably settings.ini entries that can do the same things GDK_SCALE and GDK_DPI_SCALE can do, but i can't name them off the top of my head.

You can adjust GDK_DPI_SCALE in real time if you run with GTK_DEBUG=interactive (the slider is in the Interactive tab of the GTK Inspector).

As for this bug report, on the face of it, "fractional scaling is not supported", i guess the reaction should be "won't fix"? GTK developers are aware that non-integer scaling is desirable, but it will definitely not happen in GTK3. As for doing it for GTK4, i am not aware of any consensus on how to implement it.

I do not understand: Gimp and Inkscape, which are both based on GTK+, do scale well on my windows 10 machine with a zoom of 150%.
Why gedit cannot do that?
Moreover, I saw blog posts about fractional scaling coming to linux/gnome, so I thought that GTK+ was supporting it.

GIMP and Inkscape use GTK2 (as far as i know), which doesn't support scaling at all (thus Windows handles all the scaling, just as it does with all old apps). gedit uses GTK3, which does tell Windows that it understands scaling, but then doesn't scale anything (since fractional scaling is not supported).

The blog posts are about a recent experimental fractional scaling in Gnome when using Wayland compositor. It appears that GTK just told to make windows bigger than needed (with a higher integer scale factor N), and then the result is scaled down in the compositor to achieve fractional scaling X, where N-1 < X < N.

I am currently not sure how this could be ported to Windows, since we can't change anything in the Windows compositor, so we'd have to do something (scale down larger-than-needed render-buffers?) somewhere else (in GDK?) somehow (GL?)... That would be a major TODO, and i can't even begin to tell you what the performance impact would be.

Thanks for the explanation.
So, why is not possible to do like on gtk2, letting the windows compositor do the scaling? It works well on my machine.

Windows can only do non-upscaling scaling for old applications that use Windows controls, but that obviously does not cover GTK2 (or GTK3, if you try to force different DPI mode for GTK3 apps).

Windows does the built-in autoscaling for old applications by rendering a window at its normal, 100% size, and then *upscaling* it to 125%, 150% or 175% (or whatever). Upscaling is *bad*, as it tries to create new pixel data out of thin air. Downscaling is *less bad*, as it just loses pixel data. I'm surprised that you are able to tolerate upscaling, it usually just blurs everything, really.

Created attachment 368795 [details]
screenshot of inkscape and gedit with fractional scaling on windows

The upscaling of gtk2 works quite well in my opinion.
Attached is a screenshot comparing inkscape and gedit on my screen.

Inkscape does look unexpectedly better than gedit on that screenshot. What happens when you change DPI compatibility settings for gedit?

I have 200% scaling (resulting in quite different picture), and you need to re-login into your session to apply your changes if you change desktop scaling factor, so testing 150% is...inconvenient for me.

Hi Frédéric,

Hmm, it might be so that Inkscape has embedded an application manifest[1] so that DPI awareness is activated (I didn't test myself, but it seems so to me from the screenshot).

On Windows, whether to activate DPI awareness (thus HiDPI support) is first deteremined whether the application has a manifest which says whether the application is DPI-aware, or whether that DPI-awareness should not be activated at all [1].

As LRN mentioned, there is no built-in HiDPI support for GTK+-2.x, which is what Inkscape uses, and there is integer scaling support for GTK+-3.x[2] built into GTK+ (which is what GEdit uses, which I believe does not ship with the GTK+-3.22.x DLLs from its last binary release), which is always activated unless the a compatibility setting is set not to use it, or when an application manifest[1] which tells Windows not to enable DPI awareness is used, or when the GDK_WIN32_DISABLE_HIDPI is set.  In all cases for GTK+-3.x, the application manifest setting, if present, always prevails.

So, as LRN mentioned, this will be a "won't fix" for GTK+-2.x and GTK+-3.x.

---
Hi LRN,

I think, if I recall correctly, Windows does support float scale factors, but since this will be for GTK+-4.x or later, we need to focus there when things are clearer.

---

With blessings, and cheers!

---

[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/mt843498(v=vs.85).aspx
[2]: GTK+-3.x needs to be 3.22.4 or later, 3.22.19 or later is recommended--can you please find the GTK+-3.x DLL (libgtk-3.dll or so) that your copy of GEdit uses, right click on it, and select "properties", and see what version that GTK+ dll is?

> I think, if I recall correctly, Windows does support float scale factors,
> but since this will be for GTK+-4.x or later, we need to focus there when
> things are clearer.

Not necessarily for GTK4 or later. Scaling support is opaque (GTK continues to use "logical" pixels and does not know the real size of GDK windows underneath), so, theoretically, it could be possible to somehow implement fractional scaling. GDK could tell GTK to render at 2x resolution (as if GDK_SCALE=2 was in effect), and then scale the rendered buffer down to 1.5x or 1.25x (or whatever) of the normal resolution to achieve fractional scaling. All the machinations with coordinates and such will be happening inside W32 GDK backend, so it should be backward-compatible and thus fit for GTK3. Anyway, that's my theory so far.

Created attachment 368817 [details]
screenshot of inkscape and gedit with fractional scaling on windows, with gedit DPI setting managed by the application

Thanks to LRN's comment, I changed the DPI setting of gedit.exe so that it is managed by the application. Now the result is good! (see attached screenshot)

So apparently, it changes only the fonts size, not the size of the other UI elements, which is not perfect. Still, I prefer that to having blurry fonts.

To answer Fan's comment, gtk is 3.20.2 for gedit on windows.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/1036.