geeqie geeqie 2.6.1 on Arch Linux is still slow on HIDPI wayland

Setup (please complete the following information):

Distribution: Arch Linux
GUI: KDE Plasma Wayland
Geeqie version: Geeqie 2.6.1 GTK3

Describe the bug The performance of GDK_BACKEND=x11 is by an order of magnitude better than GDK_BACKEND=wayland on 3840x2160 resolution.

Screencast https://github.com/user-attachments/assets/2aa7bbdf-7f00-499f-8dee-2290529027fb

Error logs or seg. fault files If applicable, upload text files from the bug. (Use gzip)

Additional context A follow-up for #1743

Jun 11 '25 12:06 Felixoid

I'm also on Arch Linux (the maintainer of the Geeqie package) and am not able to replicate this. I am on Hyprland, not KDE/Plasma, but running with ether backend gives me results similar enough that I can't tell the difference. Both of them are far more laggy than I would like and much laggier than I remember Geeqie being back in the day on older hardware, but it isn't anything like the results in your screencase.

I do wonder if the backend is even taking effect for me, perhaps it is unable to startup X11 windows at all for me? I wonder how we're supposed to confirm that bit.

Also do you happen to have any other DE/WM environments installed you could test besides KDE/Plasma?

Jun 11 '25 12:06 alerque

Both of them are far more laggy than I would like and much laggier than I remember Geeqie being back in the day on older hardware,

For interest only - GQview still runs on my system - Ubuntu 25.04: wget https://cclark.uk/GQview/gqview

Jun 11 '25 15:06 caclark

I am not able to replicate this

It's valid only for a maximized window on a HIDPI screen 3840x2160. With 0.5 and even 0.8-sized windows it's much better.

I believe that x11 is installed on my system.

> pacman -Q | grep -Pi 'x11|xorg'
libx11 1.8.12-1
libxkbcommon-x11 1.10.0-1
qt5-x11extras 5.15.17-1
xorg-fonts-encodings 1.1.0-1
xorg-mkfontscale 1.2.3-1
xorg-server 21.1.16-1
xorg-server-common 21.1.16-1
xorg-server-xvfb 21.1.16-1
xorg-setxkbmap 1.3.4-2
xorg-xauth 1.1.4-1
xorg-xdpyinfo 1.3.4-2
xorg-xkbcomp 1.4.7-1
xorg-xmessage 1.0.7-1
xorg-xprop 1.2.8-1
xorg-xrandr 1.5.3-1
xorg-xrdb 1.2.2-2
xorg-xset 1.2.5-2
xorg-xwayland 24.1.6-1
xorgproto 2024.1-2

Jun 13 '25 08:06 Felixoid

Using EndeveaourOS, a 3840x2160 display, a Radeon RX550 card, and Wayland, I do not see the problem.

Jun 18 '25 15:06 caclark

Same issue here sill, slow screen updates advancing though images, even slower when fullscreen. GIFs really highlight the problem, it can't even draw the full image. 2560x1440, RX 6800XT, Wayland, UI scale 125%. GDK_BACKEND=x11 is better but still not good compared to 2.5 using wayland backend. #1743

Jun 18 '25 22:06 eh

It's still pretty pokey on Arch Linux, X (not Wayland), HiDPI, at least after changing directories (2-3 minute wait). Out of scope for this ticket, though.

Jun 19 '25 01:06 virtadpt

2-3 minutes! On X not wayland? That sounds like a different issue than this one, but it's hard to be sure without an actual diagnosis for either issue.

I think we need some input from devs here on how to debug this. Clearly there is something serious going on, but I don't see any obvious culprit.

Jun 19 '25 07:06 alerque

Possible items of interest are: OS gpu card screen resolution, scaling X11/Wayland drive local or remote drive format type

To isolate the problem try to simplify every aspect, and if that is OK work from there to find the critical factor. If a minimum system exhibits the problem, I am out of ideas.

Use a default config. - rename $HOME/.config/geeqie/geeqierc.xml or run geeqie by: XDG_CONFIG_HOME=/tmp/a XDG_CACHE_HOME=/tmp/b geeqie

Start geeqie with no files: geeqie /tmp/empty-dir1

Use a low-res. screen setting and scale=1

Use only local drives and ext4

If you are compiling from sources, use geeqie --debug=4

Also consider trying the minimal AppImage - that is compiled with all optional extras disabled:

wget https://github.com/BestImageViewer/geeqie/releases/download/continuous/Geeqie-minimal-latest-x86_64.AppImage

Jun 19 '25 14:06 caclark

@alerque Yup. It's irritating enough that I've tried multiple times to go back to gqview (which doesn't compile anymore). It's at the point where I plan sorting through archived scans around how long it takes for geeqie to become usable.

I've been quietly excavating the tickets and trying all of the suggestions for this (and similar) problems. I can reproduce the outputs but not the fixes.

Jun 20 '25 01:06 virtadpt

@caclark I have the appimage in question downloaded; I'll give it a spin after work tonight.

As for my setup, details to come.

Jun 20 '25 01:06 virtadpt

OS

Arch Linux

gpu card

04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lucienne (rev c1)

screen resolution, scaling

3840x2160, 125%

X11/Wayland

Wayland, ~will check X11 in a moment after the comment, need to reboot~ I don't have X11

drive local or remote

Local drive, SSD

drive format type

/dev/mapper/cLVM-local on /home type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

XDG_CONFIG_HOME=/tmp/a XDG_CACHE_HOME=/tmp/b geeqie

The effect is the same; it's scrolling and loading pictures very slowly.

geeqie /tmp/empty-dir1

So, it started quickly. But the pictures' scrolling is still slow

wget https://github.com/BestImageViewer/geeqie/releases/download/continuous/Geeqie-minimal-latest-x86_64.AppImage

It's slow as well, the logs are attached.

The command I ran is XDG_CONFIG_HOME=/tmp/a XDG_CACHE_HOME=/tmp/b ./Geeqie-minimal-latest-x86_64.AppImage /tmp/b --debug=4 | ts %.T &> /tmp/geeqie.log

geeqie.log

Jul 16 '25 20:07 Felixoid

@Felixoid Does the problem exist if you use integer scaling for the display?

Edited to add: Does the option Edit/Preferences/Image/Two Pass have an influence?

Jul 18 '25 15:07 caclark

Yes, 100% changes nothing

Jul 18 '25 15:07 Felixoid

Has anyone tried:

GQ_DISABLE_CLUTTER=y geeqie

Jul 21 '25 10:07 caclark

Has anyone tried:

GQ_DISABLE_CLUTTER=y geeqie

XDG_CONFIG_HOME=/tmp/a XDG_CACHE_HOME=/tmp/b GQ_DISABLE_CLUTTER=y /tmp/Geeqie-minimal-latest-x86_64.AppImage /tmp/b --debug=4 - no effect

Edited to add: Does the option Edit/Preferences/Image/Two Pass have an influence?

I tried it, but the full time of the image loading doesn't change. It's just loading now square-by-square

https://github.com/user-attachments/assets/0d4bab7e-0282-4d50-b184-ddf031732db8

geeqie.log

And this grid is always visible on the images, regardless of how I open it.

Jul 21 '25 10:07 Felixoid

Rollback to 2.5 is the best medicine so far =(

Aug 04 '25 09:08 Felixoid

Can I add here something to help fixing it?

Sep 10 '25 11:09 Felixoid

@Felixoid

Of course.

Sep 10 '25 17:09 caclark

I mean, any debug information that would add value.

Although I launched the AppImage with strace and flamegraph wrapper.

HOME=/tmp/a XDG_CONFIG_HOME=/tmp/a XDG_CACHE_HOME=/tmp/b flamegraph -o my_flamegraph.svg -- /tmp/.mount_GeeqieHNdacb/AppRun /tmp/b

HOME=/tmp/a XDG_CONFIG_HOME=/tmp/a XDG_CACHE_HOME=/tmp/b strace /tmp/.mount_GeeqieHNdacb/AppRun /tmp/b |& ts %.T > /tmp/geeqie.strace

In strace the drawing has huge amount of clock_gettime ans a bit lower gettimeofday

awk '{print $2}' < ../geeqie.strace | sort | uniq -c | sort -n | tail
    562 futex(0x7f1000df1018,
    602 lseek(12,
    629 gettimeofday({tv_sec=1757582167,
    733 ppoll([{fd=3,
    757 read(15,
    800 read(12,
    848 openat(AT_FDCWD,
   1177 newfstatat(AT_FDCWD,
   3714 gettimeofday({tv_sec=1757582153,
  33703 clock_gettime(CLOCK_MONOTONIC,

And I am not sure how to interpret the flamegraph.

The SVG doesn't look correct if opened in Firefox, but save/open works better

strace.tar.gz

Sep 11 '25 09:09 Felixoid

My read is that the vast majority of the time being spent is being consumed by libpixman-1.so.0, a shared library provided by Arch's pixman package, not directly consumed by the Geeqie binary—more like by something it is calling out to have done for it. That's definitely a clue.

Sep 11 '25 19:09 alerque

It's the appimage mounted directory, I'm not sure for 100%, but the so file should be a well from appimage?

Will check it tomorrow

Sep 11 '25 22:09 Felixoid

Indeed, all the mentioned files from the flamegraph are embedded into AppImage:

> ls -l /tmp/.mount_GeeqiejaKLFP/**/{libgtk-3.so.0,libcairo.so.2,libpixman-1.so.0}
-rw-r--r-- 1 root root 1598200 Sep 10 10:45 /tmp/.mount_GeeqiejaKLFP/usr/lib/libcairo.so.2
-rw-r--r-- 1 root root 8952664 Sep 10 10:45 /tmp/.mount_GeeqiejaKLFP/usr/lib/libgtk-3.so.0
-rw-r--r-- 1 root root 1145120 Sep 10 10:45 /tmp/.mount_GeeqiejaKLFP/usr/lib/libpixman-1.so.0

Sep 12 '25 09:09 Felixoid

If you are on Arch Linux why don't you use the Arch Linux package? And If you get the same slow-downs with the system packaged version, the same performance profiling might tell a more interesting story.

Sep 12 '25 20:09 alerque

What does this command show? glxinfo -B | egrep 'renderer|version'

Sep 13 '25 13:09 caclark

@alerque Because the same thing happens. I can't speak for everyone else commenting on this ticket but I started using the AppImage to help debug (vis a vis, figure out if it's in the Geeqie code or in a library).

@caclark

Extended renderer info (GLX_MESA_query_renderer):
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL renderer string: Mesa Intel(R) Graphics (MTL)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.1.6-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.1.6-arch1.1
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.1.6-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Sep 13 '25 23:09 virtadpt

Please run this script and upload the output:

diag-gtk-perf.sh.gz

Sep 14 '25 10:09 caclark

If zoom is set to original size is the speed affected?

Sep 15 '25 14:09 caclark

Please run this script and upload the output:

diag-gtk-perf.sh.gz

Output

> bash diag-gtk-perf.sh

────────── BASICS ──────────
Host:        slim-click
OS:          Arch Linux
Kernel:      6.16.5-arch1-1
Arch:        x86_64
Time:        2025-09-15T18:03:22+02:00

────────── SESSION / DISPLAY ──────────
XDG_SESSION_TYPE:   wayland   # wayland or x11
XDG_CURRENT_DESKTOP:KDE
DESKTOP_SESSION:    plasma
WAYLAND_DISPLAY:    wayland-0
DISPLAY:            :1

────────── GTK / SCALING ENV ──────────
GDK_BACKEND:        <unset>
GDK_SCALE:          <unset>
GDK_DPI_SCALE:      <unset>
QT_SCALE_FACTOR:    <unset> (for cross-checks)
CLUTTER_DEFAULT_FPS:<unset> (legacy but sometimes set)

────────── GNOME/KDE SETTINGS (if available) ──────────
GNOME scaling-factor:     uint32 1
GNOME text-scaling-factor:1.0
GNOME fractional-scaling: N/A
GTK theme:                'Breeze'
Icon theme:               'breeze-dark'

────────── GTK/GLIB VERSIONS ──────────
GTK3 via pkg-config: 3.24.50
GLib via pkg-config: 2.84.4

────────── GPU / DRIVER / MESA ──────────
glxinfo -B:
  name of display: :1
  display: :1  screen: 0
  direct rendering: Yes
  Extended renderer info (GLX_MESA_query_renderer):
      Vendor: AMD (0x1002)
      Device: AMD Radeon Graphics (radeonsi, renoir, ACO, DRM 3.64, 6.16.5-arch1-1) (0x164c)
      Version: 25.2.2
      Accelerated: yes
      Video memory: 512MB
      Unified memory: no
      Preferred profile: core (0x1)
      Max core profile version: 4.6
      Max compat profile version: 4.6
      Max GLES1 profile version: 1.1
      Max GLES[23] profile version: 3.2
  Memory info (GL_ATI_meminfo):
      VBO free memory - total: 27 MB, largest block: 27 MB
      VBO free aux. memory - total: 28234 MB, largest block: 28234 MB
      Texture free memory - total: 27 MB, largest block: 27 MB
      Texture free aux. memory - total: 28234 MB, largest block: 28234 MB
      Renderbuffer free memory - total: 27 MB, largest block: 27 MB
      Renderbuffer free aux. memory - total: 28234 MB, largest block: 28234 MB
  Memory info (GL_NVX_gpu_memory_info):
      Dedicated video memory: 512 MB
      Total available memory: 32349 MB
      Currently available dedicated video memory: 27 MB
  OpenGL vendor string: AMD
  OpenGL renderer string: AMD Radeon Graphics (radeonsi, renoir, ACO, DRM 3.64, 6.16.5-arch1-1)
  OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.2.2-arch1.2
  OpenGL core profile shading language version string: 4.60
  OpenGL core profile context flags: (none)
  OpenGL core profile profile mask: core profile

  OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.2-arch1.2
  OpenGL shading language version string: 4.60
  OpenGL context flags: (none)
  OpenGL profile mask: compatibility profile

  OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.2.2-arch1.2
  OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

vulkaninfo (GPU summary):
                GPU id = 0 (AMD Radeon Graphics (RADV RENOIR))
                GPU id = 0 (AMD Radeon Graphics (RADV RENOIR))
                GPU id = 0 (AMD Radeon Graphics (RADV RENOIR))
                GPU id = 0 (AMD Radeon Graphics (RADV RENOIR))
                GPU id = 0 (AMD Radeon Graphics (RADV RENOIR))
                GPU id = 0 (AMD Radeon Graphics (RADV RENOIR))
  GPU id : 0 (AMD Radeon Graphics (RADV RENOIR)) [VK_KHR_xcb_surface, VK_KHR_xlib_surface]:
  GPU id : 0 (AMD Radeon Graphics (RADV RENOIR)) [VK_KHR_wayland_surface]:
        driverName                                           = radv
PCI GPU:
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lucienne (rev c1)
        Subsystem: AIstone Global Limited Device 115d
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

────────── COMPOSITOR / SHELL ──────────
kwin_wayland: QThreadStorage: entry 8 destroyed before end of thread 0x562267d667e0
QThreadStorage: entry 1 destroyed before end of thread 0x562267d667e0
QThreadStorage: entry 0 destroyed before end of thread 0x562267d667e0
kwin 6.4.4
Xorg:        /usr/lib/Xorg.wrap: Only console users are allowed to run the X server
Xwayland:    The X.Org Foundation Xwayland Version 24.1.8 (12401008)

────────── MONITORS / SCALE (approx) ──────────
xrandr --query:
  Screen 0: minimum 16 x 16, current 4992 x 1728, maximum 32767 x 32767
  eDP-1 connected 1920x1080+0+462 (normal left inverted right x axis y axis) 309mm x 174mm
     1920x1080     59.96*+
     1440x1080     59.99
     1400x1050     59.98
     1280x1024     59.89
     1280x960      59.94
     1152x864      59.96
     1024x768      59.92
     800x600       59.86
     640x480       59.38
     320x240       59.29
     1680x1050     59.95
     1440x900      59.89
     1280x800      59.81
     1152x720      59.97
     960x600       59.63
     928x580       59.88
     800x500       59.50
     768x480       59.90
     720x480       59.71
     640x400       59.95
     320x200       58.14
     1600x900      59.95
     1368x768      59.88
     1280x720      59.86
     1024x576      59.90
     864x486       59.92
     720x400       59.27
     640x350       59.28
  DP-1 connected primary 3072x1728+1920+0 (normal left inverted right x axis y axis) 697mm x 392mm
     3072x1728     59.94*+
     2048x1536     59.95
     1920x1440     59.90
     1600x1200     59.87
     1440x1080     59.99
     1400x1050     59.98
     1280x1024     59.89
     1280x960      59.94
     1152x864      59.96
     1024x768      59.92
     800x600       59.86
     640x480       59.38
     320x240       59.29
     2560x1600     59.94
     1920x1200     59.88
     1680x1050     59.95
     1440x900      59.89
     1280x800      59.81
     1152x720      59.75
     960x600       59.63
     928x580       59.88
     800x500       59.50
     768x480       59.90
     720x480       59.71
     640x400       59.95
     320x200       58.14
     2880x1620     59.96
     2560x1440     59.96
     2048x1152     59.90
     1920x1080     59.96
     1600x900      59.95
     1368x768      59.88
     1280x720      59.86
     1024x576      59.90
     864x486       59.92
     720x400       59.27
     640x350       59.28
DRM connectors (modes & scale hints):
  /sys/class/drm/card1-DP-1/status:connected
  /sys/class/drm/card1-eDP-1/status:connected
  /sys/class/drm/card1-HDMI-A-1/status:disconnected
  /sys/class/drm/card1-DP-1/modes:3840x2160
  /sys/class/drm/card1-DP-1/modes:3840x2160
  /sys/class/drm/card1-DP-1/modes:1920x2160
  /sys/class/drm/card1-DP-1/modes:2560x1440
  /sys/class/drm/card1-DP-1/modes:1920x1200
  /sys/class/drm/card1-DP-1/modes:1920x1080
  /sys/class/drm/card1-DP-1/modes:1920x1080
  /sys/class/drm/card1-DP-1/modes:1920x1080
  /sys/class/drm/card1-DP-1/modes:1920x1080
  /sys/class/drm/card1-DP-1/modes:1600x1200
  /sys/class/drm/card1-DP-1/modes:1680x1050
  /sys/class/drm/card1-DP-1/modes:1280x1024
  /sys/class/drm/card1-DP-1/modes:1280x1024
  /sys/class/drm/card1-DP-1/modes:1440x900
  /sys/class/drm/card1-DP-1/modes:1280x960
  /sys/class/drm/card1-DP-1/modes:1280x800
  /sys/class/drm/card1-DP-1/modes:1280x720
  /sys/class/drm/card1-DP-1/modes:1280x720
  /sys/class/drm/card1-DP-1/modes:1280x720
  /sys/class/drm/card1-DP-1/modes:1280x720
  /sys/class/drm/card1-DP-1/modes:1024x768
  /sys/class/drm/card1-DP-1/modes:1024x768
  /sys/class/drm/card1-DP-1/modes:1024x768
  /sys/class/drm/card1-DP-1/modes:832x624
  /sys/class/drm/card1-DP-1/modes:800x600
  /sys/class/drm/card1-DP-1/modes:800x600
  /sys/class/drm/card1-DP-1/modes:800x600
  /sys/class/drm/card1-DP-1/modes:800x600
  /sys/class/drm/card1-DP-1/modes:720x576
  /sys/class/drm/card1-DP-1/modes:720x576
  /sys/class/drm/card1-DP-1/modes:720x480
  /sys/class/drm/card1-DP-1/modes:720x480
  /sys/class/drm/card1-DP-1/modes:720x480
  /sys/class/drm/card1-DP-1/modes:720x480
  /sys/class/drm/card1-DP-1/modes:640x480
  /sys/class/drm/card1-DP-1/modes:640x480
  /sys/class/drm/card1-DP-1/modes:640x480
  /sys/class/drm/card1-DP-1/modes:640x480
  /sys/class/drm/card1-DP-1/modes:640x480
  /sys/class/drm/card1-DP-1/modes:640x480
  /sys/class/drm/card1-DP-1/modes:720x400
  /sys/class/drm/card1-eDP-1/modes:1920x1080
  /sys/class/drm/card1-eDP-1/modes:1920x1080
  /sys/class/drm/card1-eDP-1/modes:1680x1050
  /sys/class/drm/card1-eDP-1/modes:1280x1024
  /sys/class/drm/card1-eDP-1/modes:1440x900
  /sys/class/drm/card1-eDP-1/modes:1280x800
  /sys/class/drm/card1-eDP-1/modes:1280x720
  /sys/class/drm/card1-eDP-1/modes:1024x768
  /sys/class/drm/card1-eDP-1/modes:800x600
  /sys/class/drm/card1-eDP-1/modes:640x480

────────── CPU / GOVERNOR (scheduling can affect jank) ──────────
CPU:   Architecture:                            x86_64
  CPU op-mode(s):                          32-bit, 64-bit
  Address sizes:                           48 bits physical, 48 bits virtual
  Byte Order:                              Little Endian
  CPU(s):                                  16
  On-line CPU(s) list:                     0-15
  Vendor ID:                               AuthenticAMD
  Model name:                              AMD Ryzen 7 5700U with Radeon Graphics

────────── RUN-TIME CHECKS ──────────
Test forcing backends (try these manually):
  GDK_BACKEND=x11 GTK_THEME=Adwaita GDK_SCALE=1 <your-app>
  GDK_BACKEND=wayland GTK_THEME=Adwaita GDK_SCALE=2 <your-app>
If one is smooth and the other is laggy, backend/scale is the cause.

────────── DONE

If zoom is set to original size is the speed affected?

No, it's slow in any case.

Changing display scale from 125% to 100% helps a little bit, but not completely. It's still slow. Faster, maybe, 5 times that with scale, but still spends second or so on bit images to render completely.

Sep 15 '25 16:09 Felixoid

@alerque as noted, I follow the request to use AppImage as a point of true to debug the issue, here's the source https://github.com/BestImageViewer/geeqie/issues/1743#issuecomment-2862514943

Sep 15 '25 16:09 Felixoid