Dragging window slow on proprietary driver

[fundies]

When dragging the window it takes a while to catch up with the mouse cursor. This only happens on nvidia drivers (nouveau on same card is fine) and seems to only effect glfw. Dragging a sfml window behaves fine for example.

here is a video showing the lag: https://youtu.be/1j1wDrOqQyM

ArchLinux 4.10.13-1-ARCH community/glfw-x11 3.2.1-1 [installed] extra/nvidia 381.22-1 [installed]

01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)

I've tried with vsync on and off and pollevents vs waitevents but has made no difference. I'm using the code here: http://www.glfw.org/documentation.html

[elmindreda]

Did the SFML window have an OpenGL context and were you swapping its buffers?

[fundies]

yes

[gollum1001]

I can reproduce it Kubuntu 17.04 Glfw 3.2.1-1 ( and 67c9155 ) Nvidia driver 381.22

For me glfwSwapInterval(0); has helped, but is not a real option.

[felselva]

Ok, this might be a long shot, but can you try with glfwSwapInterval(1) and call glFinish() before/after glfwSwapBuffers().

Another long shot: call glFlush() right after your render is done.

Try a combination of these. I found that this is a recurring NVIDIA problem of CPU-GPU synchronization, and also happened with some DEs in the past (Unity, Gnome).

Docs for glFinish():

• https://www.khronos.org/opengl/wiki/Swap_Interval

• https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glFinish.xhtml

Docs for glFlush():

• https://www.khronos.org/opengl/wiki/GLAPI/glFlush

• https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glFlush.xhtml

[gollum1001]

I have updated NVIDIA driver to 384.59, but nothing changes.

glFinish and glFlush have not helped.

[felselva]

I'm starting to believe the issue is not related with GPU. My shot with glFlush() or glFinish() was because SFML has glFlush() in some of its drawing functions, and glFinish() is similar, but with blocking behavior.

I wonder if this could be related with event polling, instead? Could _glfwDetectJoystickConnectionLinux()[1] be taking too long?

[1] https://github.com/glfw/glfw/blob/213dd2d0d6201a1e17dacce2ff35bdc8dd14e309/src/x11_window.c#L2346

[elmindreda]

I recall seeing @fundies issue on some machines specifically on Xfce with compositing enabled.

@gollum1001 You're running Kubuntu but are you running KDE?

[gollum1001]

I am running xfce, but ForceFullCompositionPipeline is true. I think a have added it,because VSync was not working.

Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" Option "TripleBuffer" "True" SubSection "Display" Depth 24 EndSubSection EndSection

Edit: removed (linebreak removing) code block around Xorg.conf snippet.

[elmindreda]

Right. I think this is an Xfce bug. I've seen it happen to video players as well. I'm not closing this issue, but that's my guess.

[gollum1001]

Which video player ? mplayer (with vdpau backend) and parole doesn`t have these problem.

If one glfw window is open, all windows are lagging, even a glfw window without glfwSwapBuffers(). Have you closed all glfw-based program before trying it and does other windows lag too, if you open this Video Player ?

[elmindreda]

I don't remember. VLC or Totem. It occurred even when no GLFW program was running.

Today I can reproduce it with glxgears on my GTX 660M with 375.66 running MATE, but again only when running the hardware compositor.

[gollum1001]

Yes, glxgears has this problem too.

I found this thread: https://devtalk.nvidia.com/default/topic/860367/linux/window-drag-lag-with-geforce-gtx-750-cinnamon-gnome-unity/1

Some of them think that this problem does not exist with wayland and that export CLUTTER_VBLANK=none in /etc/environment helps.

[gollum1001]

CLUTTER_VBLANK=none has reduced the effect, but has not solved it.

Changing Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" to Option "metamodes" "nvidia-auto-select +0+0" has not helped too.

[gollum1001]

CLUTTER_VBLANK=none has reduced the effect, but has not solved it.

Changing Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" to Option "metamodes" "nvidia-auto-select +0+0" has not helped too.

[elmindreda]

The recent update of the xsync branch may help with this. Please test if you are able.

[gollum1001]

It is better, but not gone

[gollum1001]

Disabling Window Manager Tweaks -> Compositor -> Enable display compositing fixed it for me.

[iongion]

As of Feb 02, 2018, this is still an issue with nvidia drivers, I have a 1080 Ti with nvidia-390 proprietary drivers. Disabling compositor does help, but that makes the desktop ugly :(, is there nothing that can be done from glfw to bypass this nivida stuff ? I cannot expect the users to disable display composition :(

[paulwedeck]

Yes but only if you have less than a few hundred fps [1] or swap buffers.

1: tests/tearing is not lagging with interval = 0

[99991]

Steam is also affected by this bug, but they seem to be using X11 directly instead of glfw:

ldd /usr/games/steam.real

    linux-gate.so.1 =>  (0xf7f43000)
    libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7b3a000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7b31000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7adc000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7ad7000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7960000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7942000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf778c000)
    libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7766000)
    /lib/ld-linux.so.2 (0xf7f45000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7749000)
    libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf7745000)
    libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf773d000)

System info:

nvidia-smi | grep Driver && grep "PRETTY_NAME" /etc/os-release && echo $DESKTOP_SESSION

| NVIDIA-SMI 396.82                 Driver Version: 396.82                    |
PRETTY_NAME="Ubuntu 16.04.6 LTS"
Lubuntu

Steps to reproduce:

1. Run steam or compile and run this

   
   #include <GLFW/glfw3.h>
   #include <unistd.h>

int main(void){ glfwInit(); glfwCreateWindow(100, 100, "Title", NULL, NULL); while (1) usleep(1000); }

2. All windows (not just this window) will start to lag when dragging.

I could not observe any difference with various combinations of `glfwSwapInterval`, `glFinish`, `glFlush`, `glfwPollEvents` or `glfwSwapBuffers`, however, the length of the lag seems to be related to the window size.

[linkmauve]

Have you reported this bug to Nvidia? It seems to only apply to their driver, I can’t reproduce on Intel at all.

[ioquatix]

Was there any response from Nvidia?

[rozniak]

This no longer seems to be a problem for me, can anyone else confirm?

I'm on Debian 11, NVIDIA Driver 465.27, Linux 5.10.46-4. Dragging glxgears or my own GLFW application no longer causes everything else on the system to slow to a crawl.

[LucasM127]

Noticing glfw windows are moving laggy when second display is active. Is fine with just one window active though. Nvidia driver on linux mint. (470.63.01-0ubuntu0.20.04.2) Xorg process seems to jump to high cpu usage when moving window around with mouse according to top command.

[nicokimmel]

Still happens for me on Arch, Nvidia 510, Zen Kernel, Gnome 42. The ideas above do not work for me. (Beside glfwSwapInterval(0);)

Edit: Its not happening for me under Wayland instead of X11. But I need the full screen share, thats not yet working under Wayland.

[don6502]

Picom was the issue with my setup.

My setup:

• OS: Arch Linux
• Kernel: 5.17.4-arch1-1
• WM: Openbox
• Driver: nvidia 510.60.02-16

Fix:

killall picom

[dylrich]

I can also reproduce reliably. glfwSwapInterval(0) fixes it, but this is not a real fix I can use. Would love to try stuff out if anyone has any ideas. I've tried every fix listed above so far, no dice.

• Fedora 36
• Kernel 5.18.5-200 x86_64
• Gnome 42 with X11
• Nvidia driver 510.68.02
• glfw 3.3, opengl 3.3

[ravimohan1991]

Ok, this might be a long shot, but can you try with glfwSwapInterval(1) and call glFinish() before/after glfwSwapBuffers().

Another long shot: call glFlush() right after your render is done.

Try a combination of these. I found that this is a recurring NVIDIA problem of CPU-GPU synchronization, and also happened with some DEs in the past (Unity, Gnome).

Docs for glFinish():

* https://www.khronos.org/opengl/wiki/Swap_Interval

* https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glFinish.xhtml

Docs for glFlush():

* https://www.khronos.org/opengl/wiki/GLAPI/glFlush

* https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glFlush.xhtml

Thanks a lot to @felselva, the issue is almost gone on Ubuntu 22.04 using default Nvidia proprietary (additional) driver.

[nicokimmel]

@ravimohan1991 I think this is only the case because Ubuntu 22.04 defaults you to Wayland even with Nvidia drivers. And the problem does not exist there.

[zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a]

Cannot reproduce on both FreeBSD release 13 and Debian 11.2 using xfwm.

[ravimohan1991]

@ravimohan1991 I think this is only the case because Ubuntu 22.04 defaults you to Wayland even with Nvidia drivers. And the problem does not exist there.

Not quite, I followed the tutorial and the issue is invariant.

On a completely unrelated topic, is there similar remedy for Vulkan with same conditions?

[psiwray]

I have the same behavior, disabling vertical sync helped but it's not really what I want. I have a GTX 1070 on Ubuntu 22.04 with proprietary drivers to the latest (as of now) version 515.65.01. Any updates?

Switching to Wayland makes the issue disappear for me too but I can't use it because it lacks some features as mentioned above.

[z-targz]

Still have this issue ubuntu 22.04 gnome

[pavelverigo]

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1799679 https://gitlab.gnome.org/GNOME/mutter/-/issues/2233#note_1575235 Using nvidia-driver-525 on Ubuntu 22.04 fixed the issue.

[ioquatix]

My own anecdotal evidence suggests that the issue is happening less often than it used to. But, I still feel like in the past month I've seen it happen once or twice (flickering).

[Sophed]

I'm having a very similar issue on GNOME 43, Arch, Nvidia drivers and Zen Kernel

[Vaxeral]

My GLFW window is slow to drag. If i add the call glfwSwapInterval(0) the window is not slow to drag. I don't have enough expertise to come to a conclusion.

[azagaya]

Updating nvidia drivers to at least 525 fixed the issue to me in Ubuntu 22.04.

[Vaxeral]

Window is slow to drag using xlib and glx directly. calling glXSwapIntervalEXT with 1 (vsync) causes it to drag slowly.