Closed Teteros closed 4 years ago
Having the same issue, with the same packages on archlinux. Are there any tests I can do to help narrow the issue down further?
This broke neovim-gtk for me, big problem since I use it as daily driver
Looks like some size calculation issues.
Additionally to what others already said, the output also looks "blocky", especially in visual model and in the status line.
This might be a problem with anti-aliasing on edges lying close to each other. I have no idea how the rendering is actually implemented, though.
You can also read about other Pango 1.44 changes here: https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/
Any news/updates on a possible fix for this?
Does 1.44 available on ubuntu? What easiest way to reproduce this? From what i see it looks like some font metrics calculation changed.
@daa84 Not sure about ubuntu (you might be able to update to 1.44 by adding a new apt repo that contains the latest version, but that's a guess) since I use Arch, but to reproduce it all you need to do is download latest pango and start using neovim-gtk. Scroll around a file, type some text, etc.; you'll see multiple issues resulting from the pango update.
@daa84 The problem is really bad, because you can't read the text after a few lines (I run the shell from neovim-gtk also). The best I would suggest is to setup an archlinux virtual machine and run it there after updating all the packages. You will see the problem right away.
It might be wise to keep this archlinux VM around, since you will get to know breakages like this very quickly before all the other distros.
In lieu of a fix for now (potentially until ubuntu gets an updated pango), pango-ubuntu from the AUR (and the related cairo & freetype libraries pulled as dependencies) seems fix the issue on Arch for the moment, and so far hasn't caused any other issues for me.
Downgrading pango to v1.43 works for me on Arch.
It may be a problem due to the change of no longer rounding glyph sizes or font metrics. At least, that seems to be the case in GNvim (another gtk-rs frontend for nvim which has the same sort of issues from the pango update). See: https://github.com/vhakulinen/gnvim/issues/84#issuecomment-517033841
Perhaps it has to do with this pango option: https://gitlab.gnome.org/GNOME/pango/commit/77b78746c901f95ca45a9ccffe9c32a38c0fb32b
I downgraded to pango 1.43 for now.
Pango 1.44.3 makes subpixel rounding optional. Rounding glyphs to the integer grid is now the default again, see this commit. After upgrading, neovim-gtk looks better, but the visual position of the input cursor is off by roughly one character.
I still have serious problems with pango 1.44.3; they show up especially when running the terminal. As I press \<enter> the lines start to get chopped off, and when I run reset
in the shell, garbage remains on the terminal screen from the previous lines. It is better than with 1.44.1, but nonetheless unusable.
I am back to pango 1.43.
Still problems with pango 1.44.5, lines get chopped off in the termnal:
The issue in GNvim seems to be that there is a difference in the values from pango::Context.get_metrics()
between pango 1.44 and 1.43. In GNvim there is a workaround for the problems we've been seeing there which involves ceil
'ing the scaled get_metrics
values, see top of https://github.com/vhakulinen/gnvim/issues/85#issuecomment-527200720.
Thus, a workaround for Neovim-GTK might be modifying some lines here in src/render/context.rs to ceil
the scaled values like this (haven't actually tested this, and note the ceil()
at the end of each line):
CellMetrics {
pango_ascent: font_metrics.get_ascent(),
pango_descent: font_metrics.get_descent(),
pango_char_width: font_metrics.get_approximate_digit_width(),
ascent: (f64::from(font_metrics.get_ascent()) / f64::from(pango::SCALE)).ceil(),
line_height: (f64::from(font_metrics.get_ascent() + font_metrics.get_descent())
/ f64::from(pango::SCALE)
+ f64::from(line_space)).ceil(),
char_width: (f64::from(font_metrics.get_approximate_digit_width())
/ f64::from(pango::SCALE)).ceil(),
underline_position: (f64::from(
font_metrics.get_ascent() - font_metrics.get_underline_position(),
) / f64::from(pango::SCALE)).ceil(),
underline_thickness: (f64::from(font_metrics.get_underline_thickness())
/ f64::from(pango::SCALE)).ceil(),
}
}
It's possible (and probably likely) that the above is only masking the true issue. Hope it helps though.
EDIT: I did some testing, and I've modified this comment accordingly. It appears that the problem is due to a difference in the integer values from pango::Context.get_metrics()
between pango 1.44 and pango 1.43, which difference causes the CellMetrics
values to be like 18.567432780
instead of 18.0
(and thus causing the pango issues, at least for GNvim). Here's the values from some debug statements here in GNvim:
Pango v1.43.0:
[src/ui/grid/context.rs:208] fm.get_ascent() = 19456
[src/ui/grid/context.rs:209] fm.get_descent() = 7168
[src/ui/grid/context.rs:210] fm.get_approximate_digit_width() = 10240
[src/ui/grid/context.rs:211] fm.get_underline_position() = -1024
[src/ui/grid/context.rs:212] fm.get_underline_thickness() = 1024
[src/ui/grid/context.rs:213] pango::SCALE = 1024
Pango v1.44.6:
PANGO v1.44:
[src/ui/grid/context.rs:208] fm.get_ascent() = 18675
[src/ui/grid/context.rs:209] fm.get_descent() = 6442
[src/ui/grid/context.rs:210] fm.get_approximate_digit_width() = 9216
[src/ui/grid/context.rs:211] fm.get_underline_position() = -956
[src/ui/grid/context.rs:212] fm.get_underline_thickness() = 956
[src/ui/grid/context.rs:213] pango::SCALE = 1024
Hey guys, any status update on that one? It's pretty major, and I'm missing neovim-gtk!
@sebastien This may be, at least partly, an upstream issue. See https://github.com/vhakulinen/gnvim/issues/85#issuecomment-529234291. Unfortunately, I have yet to find a consistent fix (for GNvim). However, wherever the CellMetrics are in neovim-gtk, ceiling them might help most of the issues; see https://github.com/vhakulinen/gnvim/issues/85#issuecomment-529230236.
I just happened to open this up minutes after you pushed that commit, ha.
While it's slightly better, as I can actually use the editor for the most part now, things still aren't aligning quite perfectly and I've noticed a few artifacts every once in a while.
Thanks for your work on trying to fix this!
I also confirm that the pango_144_fix branch solves some of the issues for me (no black/missing redraws), but I'm seeing some problems.
1) Cursor positioning is sometimes off
2) Moving the cursor onto some text will shift the characters, as if there was extra space
Also, notice that on the screenshot above, the inversion of the )
under the cursor makes it look red, while it should probably be black.
Fix merged to master
I know this is closed, but I'm still having cursor/statusline redraw issues with the current master on arch (the statusline/tabline take a long time to update, cursor isn't drawn when moving lines up/down quickly). Could this be introduced by a still-newer version of pango? (1.44-7 currently on arch)
@GorrillaRibs I don't think your version of pango is the problem. Pango 1.44 has introduced a bunch of issues (as seen by this issue) that AFAIK haven't all been fixed (in pango or harfbuzz). You might still want to try an earlier version of pango (in the 1.44 range) from the Arch Linux Archive to see if the latest version is the problem.
@sebastien Are you still getting problems with latest master of neovim-gtk?
> yay -Q neovim-gtk-git pango
neovim-gtk-git 707-1
pango 1:1.44.7-1
I just updated pango and neovim-gtk, looks like issue is fixed for me.
Seems fixed here too!
@GorrillaRibs I'm on Arch Linux as well with fully up do date packages (including Pango 1.44.7). I just compiled the AUR package for neovim-gtk-git a few minutes ago when I saw this bug was closed at it looks perfect for me. I threw a few big files at it and my full Airline setup and it seems to be doing fine. I don't see any alignment or cursor problems at all now, which is amazing considering the mess it was up until this got fixed.
@alerque @GorrillaRibs same configuration, and it works pretty well.
Good to know, seems like there's something messed on my system specifically then (possibly related to using nvidia's PRIME offloading on a laptop? Font hinting/antialiasing?). I'll see what I can dig up, and update if I solve it. Thanks!
Also can confirm that it's fixed on Arch. Thanks so much!
@GorrillaRibs What your describing and I see in that screen shot is a completely different problem than what we've been tracking in this issue. You should open a separate issue for it. You do have a display glitch but it's unrelated.
@alerque You're right, I think I just assumed it was related as it looks similar to some of the glitches I was seeing before. I'll see if I can narrow down the issue first (try on wayland vs. xorg, other window managers) before I open an issue so we have an idea what to fix.
EDIT: Still an issue on another computer using the same fonts, but not with the default monospaced font, so maybe a problem with the font I'm using (Nerd Fonts Fira Code)
@smolck seems to be working now, I don't see the issues that I had before. Thanks a lot!
This solved it for me, even using Fira Code, but I've switched to kitty+nvim since.
Describe the bug It looks like pango 1.44 deprecated Freetype and is using Harfbuzz instead. However I have these rendering issues not only with bitmap/bdf/pcf fonts, but also with ttf/otf so it may be something extra in neovim-gtk causing it.
Rolling back to pango 1.43 fixes the issue.
Technical information (please complete the following information):