Gvim stops redrawing content after resizing on KDE desktop

[zdohnal]

Steps to reproduce

1. gvim --clean
2. resize window with mouse (usually from smaller to larger window)
3. try to write in insert mode, or enter a command

Expected behaviour

Gvim redrawing the screen, showing what user wrote if it is in correct mode

Version of Vim

9.1.0825 (the latest commit b5e7da1f27)

Environment

OS: Fedora 40
Desktop Environment: KDE
plasma-workspace-6.2.2-1.fc40.x86_64
kwayland-6.2.2-1.fc40.x86_64
kwin-6.2.2-1.fc40.x86_64
kwayland-server-5.24.5-6.fc40.x86_64

Logs and stack traces

I've tried to debug the issue a little - "frame_draw()" which I understand as a function which does the redrawing, is still called, but the screen content is not redrawn.

The content can be seen again after resizing the window from Vim command mode, or sometimes I'm able to get it updated with making the window smaller.

The original report https://bugzilla.redhat.com/show_bug.cgi?id=2322919 .

[unsaved]

Have had same exact problem since updating at about the same time. I've applied minor updates since then and still have the problem with plasma-workspace 6.2.3-1. Disappointing to have to switch to a Windows computer to run gvim.

[FocusedWolf]

IDK if related but recently i starting having an issue where i couldn't resize GVim on KDE. I noticed i could still resize if i moved the mouse slow but if i dragged passed the bounds of the window, the resize stopped and gvim became frozen ignoring all input. Right away i assumed it was Wayland. Fixed it by adding "GVIM_ENABLE_WAYLAND=1" to /etc/environment. My notes said to skip this step because gvim was capable of auto-detecting whether it was running under a Wayland session but that doesn't seem to be the case since the update. The alternate ways to set this environment variable is to put "export GVIM_ENABLE_WAYLAND=true" in /etc/locale.conf or ~/.bashrc

NOTE: The problem will come back when you do [$ sudo gvim]. You need to use [$ sudo -EH gvim]. -E is needed so the environment variables are available to the sudo instance of gvim. -H is needed so $HOME=/root instead of ~/home/$USER (a side effect of using the -E option). Supposedly adding [Defaults env_keep += "GVIM_ENABLE_WAYLAND"] to /etc/sudoers with [$ sudo EDITOR=vim visudo] would be the fix to get the simpler [$ sudo gvim] to work with Wayland, but in my testing it made no difference.

[jwakely]

Oh wow, yes, that completely fixes it.

GVIM_ENABLE_WAYLAND=1 gvim works fine and can be resized.

[unsaved]

Same for me!

Oh wow, yes, that completely fixes it.

GVIM_ENABLE_WAYLAND=1 gvim works fine and can be resized.

[jwakely]

With the environment variable set, resizing the gvim window prints these errors to the terminal:

(gvim:758888): Gdk-WARNING **: 14:25:03.223: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(gvim:758888): Gdk-WARNING **: 14:25:03.256: gdk-frame-clock: layout continuously requested, giving up after 4 tries

I don't know if that's related to the problem. Maybe when the env var isn't set, that operation never gives up and so gets stuck?

[jwakely]

With the environment variable set, resizing the gvim window prints these errors to the terminal:

(gvim:758888): Gdk-WARNING **: 14:25:03.223: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(gvim:758888): Gdk-WARNING **: 14:25:03.256: gdk-frame-clock: layout continuously requested, giving up after 4 tries

I don't know if that's related to the problem. Maybe when the env var isn't set, that operation never gives up and so gets stuck?

I don't get those warnings on Fedora 41, but do still have the resizing bug, so the warnings seem to be unrelated.

[jwakely]

Using GVIM_ENABLE_WAYLAND=1 gvim on a remote host over ssh -X (or with ForwardX11=yes) causes the gvim window to open on the remote host's local display, not on the local ssh client's display. So the env var is not a complete workaround, it's only usable when running gvim locally.

[voxik]

Just FTR, I have spent a lot of time (unsuccessfully) hunting down #12671. Given that one of the symptoms that one of the GTK timer is down, I can imagine the warning above might point to something.

[chrisbra]

I have no idea about WAYLAND, but certainly there must be a way to tell wayland where to draw the aplication. Similar like using the $DISPLAY environment variable on X11. Perhaps try to set $DISPLAY to your local PC.

[jwakely]

It's set of course (because it works over SSH without the environment variable set).

Reading around a bit, it might be necessary to use waypipe.

But if gvim was resizable when used over xwayland (or however it works) then the environment variable wouldn't be needed and so neither would waypipe

[chrisbra]

Well, it sounds like a wayland usage question to me

[jnerin]

😕 I think the wayland over ssh is another totally unrelated issue, wayland does not forward the display using the X11 protocol, so it just doesn't work using ssh -X or ssh -Y.

Barring that, I have the symptoms described in this issue. On my local machine that runs wayland natively gvim (version Gentoo-9.1.0366) just behaves as described in this bug, with no ssh or forwarding between machines involved. Using GVIM_ENABLE_WAYLAND=1 gvim makes it behave properly, there's a rendering artifact with icon sizes being bigger than they should, potentially related to being a dual display with one 4k screen with scaling enabled at 175% and another 1080p screen at 100%, but that may be due to the GTK theme or icon set; it doesn't bother me too much now, and I think it's unrelated to the window resizing bug.

I see that according to qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole plain gvim launches it in X11 mode, as it appears in the "X11 windows" section, if I launch GVIM_ENABLE_WAYLAND=1 gvim it appears in the Wayland section, and I can resize it without issues.

[jwakely]

I think the wayland over ssh is another totally unrelated issue, wayland does not forward the display using the X11 protocol, so it just doesn't work using ssh -X or ssh -Y.

Yes I agree it's unrelated, my reason for bringing it up is just that setting GVIM_ENABLE_WAYLAND=1 gvim is only a solution for local gvim sessions, because if you're using it over ssh -X then you can't define the env var, and the resizing bug is a problem again.

[jwakely]

there's a rendering artifact with icon sizes being bigger than they should, potentially related to being a dual display with one 4k screen with scaling enabled at 175% and another 1080p screen at 100%, but that may be due to the GTK theme or icon set

That reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=2121076 which is caused by a missing (or not correctly scaled) icon.