Blurry font rendering under fractional scaling on Linux

I use 125% scaling on my laptop display, and Ghosty exhibits blurry font rendering. At 100% or 200% scaling, the rendering is crisp, and at 150% or 175% it looks blurry but not as pronounced as at 125%. Here are screenshots for comparison:

100% (note that this one looks blurry in HiDPI mode simply because there aren't many pixels, but it looks sharp when rendered with 100% scaling)

125%

200%

I tried font-thicken = true mentioned in #661 and it didn't make much difference.

I'm running Ghostty built from commit b1677b8, on GNOME Wayland 46.2 and Fedora 40 Silverblue. I see in the logs that it does identify that fractional scaling should be used: Using. fractional scale 1.25 for EGL window (772 665 => 965 831).

I tried font-thicken = true mentioned in #661 and it didn't make much difference.

That's a macOS-only setting so it would make no difference on Linux/Gnome. How does text in Ghostty compare to other apps using the same font?

Other apps look crisp. Left-to-right: GNOME Terminal, Ghostty, VS Code. All at 125% scaling.

Could the difference be the background color of Ghostty? It's quite a bit lighter than Gnome terminal or VS Code.

Here's another comparison between GNOME Terminal and Ghostty with the foreground and background colors matched, and scaled up so you can see individual pixels.

It does look like some sort of scaling is off. Blurring is very frequently a scaling issue somewhere (in Ghostty or otherwise). I'll probably need more logs. Can you get more the startup logs for Ghostty (basically all the debug logs up to a blank window opening)?

info: ghostty version=0.1.0-main+b1677b89
info: ghostty build optimize=ReleaseFast
info: runtime=apprt.Runtime.gtk
info: font_backend=font.main.Backend.fontconfig_freetype
info: dependency harfbuzz=8.4.0
info: dependency fontconfig=21402
info: renderer=renderer.OpenGL
info: libxev backend=main.Backend.io_uring
info(os): setlocale from env result=en_US.UTF-8
info: reading configuration file path=/var/home/ben/.config/ghostty/config
info(config): default shell source=env value=/usr/bin/zsh
EGL API version 1.5 found
 - Vendor: Mesa Project
 - Version: 1.5
 - Device: /dev/dri/renderD128, 226 128
 - Client APIs: OpenGL OpenGL_ES
 - Extensions:
        EGL_ANDROID_blob_cache
        EGL_ANDROID_native_fence_sync
        EGL_EXT_buffer_age
        EGL_EXT_config_select_group
        EGL_EXT_create_context_robustness
        EGL_EXT_image_dma_buf_import
        EGL_EXT_image_dma_buf_import_modifiers
        EGL_EXT_pixel_format_float
        EGL_EXT_present_opaque
        EGL_EXT_protected_content
        EGL_EXT_query_reset_notification_strategy
        EGL_EXT_swap_buffers_with_damage
        EGL_IMG_context_priority
        EGL_KHR_cl_event2
        EGL_KHR_config_attribs
        EGL_KHR_context_flush_control
        EGL_KHR_create_context
        EGL_KHR_create_context_no_error
        EGL_KHR_fence_sync
        EGL_KHR_get_all_proc_addresses
        EGL_KHR_gl_colorspace
        EGL_KHR_gl_renderbuffer_image
        EGL_KHR_gl_texture_2D_image
        EGL_KHR_gl_texture_3D_image
        EGL_KHR_gl_texture_cubemap_image
        EGL_KHR_image_base
        EGL_KHR_no_config_context
        EGL_KHR_reusable_sync
        EGL_KHR_surfaceless_context
        EGL_KHR_swap_buffers_with_damage
        EGL_KHR_wait_sync
        EGL_MESA_configless_context
        EGL_MESA_drm_image
        EGL_MESA_gl_interop
        EGL_MESA_image_dma_buf_export
        EGL_MESA_query_driver
        EGL_MESA_x11_native_visual_id
        EGL_WL_bind_wayland_display
        EGL_WL_create_wayland_buffer_from_image
 - Selected fbconfig: R8G8B8A8, depth 0, stencil 0
          high depth: R16G16B16A16 float, depth 0, stencil 0
Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
Created EGL context[0x256a39d0]
Using OpenGL backend EGL
Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
Created EGL context[0x25180a90]
OpenGL version: 4.6 (core)
* GLSL version: 4.60
* Max texture size: 16384

Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: YES
    unpack-subimage: YES
    half-float: YES
    sync: YES
    base-instance: YES
    buffer-storage: YES
OpenGL version: 4.6 (core)
* GLSL version: 4.60
* Max texture size: 16384

Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: YES
    unpack-subimage: YES
    half-float: YES
    sync: YES
    base-instance: YES
    buffer-storage: YES
Creating EGL context version 3.3 (debug:no, forward:no, legacy:no, es:no)
Created EGL context[0x27a348f0]
OpenGL version: 4.6 (core)
* GLSL version: 4.60
* Max texture size: 16384

Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: YES
    unpack-subimage: YES
    half-float: YES
    sync: YES
    base-instance: YES
    buffer-storage: YES
info(grid): loaded OpenGL 4.6
info(font_shared_grid_set): font regular: Iosevka NF
info(font_shared_grid_set): font bold: Iosevka NF Bold
info(font_shared_grid_set): font italic: Iosevka NF Italic
info(font_shared_grid_set): font bold_italic: Iosevka NF Bold Italic
info(io_exec): found Ghostty resources dir: /var/home/ben/.local/share/ghostty
info(io_exec): shell integration automatically injected shell=termio.shell_integration.Shell.zsh
info(io_exec): started subcommand path=/bin/sh pid=434199
info(io_exec): subcommand cgroup=-
Using fractional scale 1.25 for EGL window (772 665 => 965 831)
info(grid): reallocating GPU buffer old=0 new=20
info(grid): reallocating GPU buffer old=20 new=105

@190n

@190n any chance you can get debug logs (build a debug version)? I'm specifically looking for the content scale Ghostty is applying rather than GTK and it looks like that's only a debug log.

Here log.txt

Is this improved at all with #2060? I think the issue is generally GTK only recently started supporting fractional scaling.

I have the same issue on my machine with a big 4k monitor. I compared with Kitty where my Terminess font is sharp and clear. Kitty does not using GTK, it directly calls X11. Why uses Ghosty GTK?

The font stack between Kitty and Ghostty is identical. We both use fontconfig + freetype + harfbuzz. So, it's a matter of getting the inputs right (DPI and so on) to get the right outputs.

Why uses Ghosty GTK?

Ghostty uses GTK for a native UI experience. Kitty doesn't have native tabs, native alert dialogs, native splits, native context menus, etc. That is an explicit design goal of Ghostty the app. This has nothing to do with font rendering. Our font rendering can be identical but the way we get surface sizes, DPI, etc. is dependent on our underlying platform.

Kitty does not using GTK, it directly calls X11.

This isn't strictly true, it uses a heavily modified fork of GLFW (which itself calls into X11, yes).

Ghostty uses GTK for a native UI experience.

Thanks for clarification.

I think that this issue has returned, at least in part, since the fix #4255 was reverted in #7233 (or, rather, because upstream disabled the workaround used by the fix). I'm not sure whether this issue should be re-opened or whether a new discussion should be created.

The "proper" solution for this seems to be that we need to rescale the OpenGL buffer to work with physical pixels rather than GTK's virtual pixels. However, this seems like it'll require substantial refactoring since the codebase uses the two interchangeably atm. See also #9795 (reply in thread) and the thread on Discord.

There indeed seems to be something going on with the font rendering these days. This is on Ghostty 1.2.3 (but the behavior is the same on main):

And this is using Ptyxis:

Ignoring the differences in line spacing, the fonts in ghostty have fuzzier edges compared to Ptyxis, something you can see when looking at the cache_control word.

At least in my case this isn't entirely a case of pedantics: I have a mild case of astigmatism and even with my glasses I find that the Ghostty text can be a bit more difficult to focus on, especially towards the end of the day/evening, while the way Ptyxis renders things is a bit easier on my eyes.

In this case the system is Fedora 43 with Gnome 49, the display is a 13.5" display with a resolution of 2880x1920 (3:2), running at 2.5x scaling (so it matches my other displays running at 2x scaling, due to the 3:2 ratio of this display). However, I'm noticing similar differences on my Eizo CS2740 (3840x2160) which uses a 2x scaling factor.

@yorickpeterse

@yorickpeterse I find kitty is much better than ghostty, too, and I'd be curious what that screenshot would look like for the content you showed above.

Kitty seems to go towards the other end of the spectrum and renders the font thinner/lighter:

To make it match Ghostty and Ptyxis in terms of gamma/contrast/thickness, I had to use the Kitty setting text_composition_strategy 1.5 30, producing the following:

In both cases Kitty renders the text sharper, ignoring the blur added by Gnome's screenshot utility (which is a long-standing issue but unrelated as it's the same for all screenshots).

While we're at it, here's Alacritty:

And here's a zoomed in (400%) comparison between Ghostty and Ptyxis for a specific word:

Ghostty	Ptyxis

Here the difference should be clearly visible when looking at the St in String, as in case of Ghostty the edges are a bit more blurry compared to Ptyxis.

I think the situation here is pretty clear and confirmed: this regressed with GTK 4.17.5, when gl-no-fractional was dropped, and Ghostty GTK does not currently handle fractional DPI scaling properly. #1938 (comment) has all the receipts.

Seems appropriate to have an open issue tracking this again, though whether to reopen this one or create a new one is for a maintainer to decide.

@danielwe

Based on the comment of @danielwe I ran a quick test with 200% scaling and a 10pt font size (instead of my default of 8pt) such that the font size is the same as before. This produces the following:

And a zoomed in version:

I'm not sure there's a clear difference here, and staring at the screen (to circumvent blurriness potentially added by GNOME's screenshot tool) I'm not sure I can see a difference that can't be attributed to the placebo effect.

Comparing the zoomed in screenshots side by side there does appear to be a difference, but Ptyxis is still the sharpest of them all:

Ghostty 8pt @ 2.5x	Ptyxis 8pt @ 2.5x	Ghostty 10pt @ 2.0x

To me, Ghostty@2.0 looks much closer to Ptyxis@2.5 than Ghostty@2.5. Ghostty@2.5 is the one that stands out.

But even Integer scaling requires upsampling if the content is rendered to logical instead of device pixels. It's a nicer problem since every logical pixel boundary aligns with a device pixel boundary, but sharpness could still suffer. So, with the caveat that I'm not very familiar with all the layers of GTK and OpenGL involved here, my guess is that sorting out the rendering canvas DPI would improve sharpness for both the integer and fractional cases.

Switch to Ptyxis for the time being

Hi everyone. I am having a similar issue on Niri/Wayland with fractional scaling. Ghostty seems to render in a blurry fashion that makes it harder for my eyes to focus. This is a zoomed comparison. Btw, the freetype-load-flag option doesn't really change how blurry it renders, just how the font lines up with the pixel, I believe.

ghostty:

kitty:

Hello. I was directed here because fonts are blurry (again) when using fractional scaling and Ghostty 1.3.0-1.fc43. Originally reported at #11401. Please note in the following screenshot how the three equal signs are different one from another. I'm using scale 125% on Fedora Silverblue 43/Gnone 49. Font is Iosevka Term ss15.

For comparison, Ptyxis renders the symbol always the same way.

ghostty --version
Ghostty 1.3.0-1.fc43

Version
  - version: 1.3.0-1.fc43
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.19.6-200.fc43.x86_64
  - desktop env   : gnome
  - GTK version   :
    build         : 4.20.3
    runtime       : 4.20.3
  - libadwaita    : enabled
    build         : 1.8.4
    runtime       : 1.8.4
  - libX11        : enabled
  - libwayland    : enabled

@fedemp

Experiencing the same as @fedemp. Also GNOME 49 with 125% scaling, and only Ptyxis rendered the font as if it was 100% scaling.

@danielwe

My font rendering is also still blurry. Using GNOME 50 with 180% scaling.

@danielwe said in discussion 11401:

Do you use fractional DPI scaling in your display configuration? If so, this is #1938 (which is closed, but should arguably be reopened since the problem reappeared due to upstream changes).

Ghostty only rasterizes a glyph once and reuses that bitmap in every cell containing that glyph, so it will always be pixel identical on the virtual screen that Ghostty renders to. But fractional upscaling from virtual to physical pixels may break this. The solution is to figure out how to once again make Ghostty render directly to physical pixels regardless of DPI scaling.

This tracks with what I'm experiencing as well.

Could this issue please be reopened?

If y'all are experiencing the same or a similar issue, please open a new discussion (link it here if you do); this issue won't be reopened.

took me a while but i just created a new discussion: #13911

gtk: support fractional surface scaling (#14269)

Navigation Menu

Repository navigation

Blurry font rendering under fractional scaling on Linux #1938

34 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Blurry font rendering under fractional scaling on Linux #1938

Description

Activity

jcollie commented on Jul 10, 2024

190n commented on Jul 10, 2024

jcollie commented on Jul 10, 2024

190n commented on Jul 10, 2024

mitchellh commented on Jul 11, 2024

190n commented on Jul 11, 2024

mitchellh commented on Jul 11, 2024

190n commented on Jul 12, 2024

mitchellh commented on Sep 3, 2024

chrboesch commented on Sep 12, 2024

mitchellh commented on Sep 12, 2024

chrboesch commented on Sep 12, 2024

34 remaining items

MithicSpirit commented on Dec 31, 2025

yorickpeterse commented on Jan 22, 2026

agriffis commented on Jan 22, 2026

yorickpeterse commented on Jan 22, 2026

danielwe commented on Jan 22, 2026

yorickpeterse commented on Jan 22, 2026

danielwe commented on Jan 22, 2026

and-rs commented on Jan 26, 2026

fedemp commented on Mar 13, 2026

schiegl commented on Mar 17, 2026

anna328p commented on May 31, 2026

00-kat commented on Jun 11, 2026

and-rs commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions