Using a large JPEG image as the background of xfce4-panel creates microstutter in graphical applications

Summary

The xfce4-panel gives users the option to select a background for panels. When using a JPEG image with high dimensions, such as a 4k desktop wallpaper, it causes frame drops in graphical applications.

example_background.zip

In the attached zip file, there is an example of an image which can be used to reproduce the issue. It is simply a fully black JPEG with the dimensions 5120x2880, which I exported in Gimp for the most basic possible example.

I have also included a 3840x60 image, because I think users making their own panel images tailored to their own resolution is probably not uncommon.

In practice, using large wallpapers as the taskbar background is not the intended use of the feature, but there are no warnings or indication to the user that they should not use a large image, or what kind of image they should use at all. So it's reasonable to assume that there are people like me who just use a wallpaper because it looks cool and I can change it easily.

My environment

Version: xfce4-panel 4.20.7

Hardware: 14600k, 4060 ti, 64gb good DDR4 RAM, three monitors.

Relevant drivers: Nvidia 580.126.09

Platform: Linux 6.12.73_1

Steps to reproduce

By using MangoHud we can monitor the FPS of an application. We will use MangoHud with GlxGears to demonstrate that changing the panel background has an impact.

  1. Back up your ~/.config/xfce4 folder
  2. Clear out all your panels, and ensure you only have a single clean panel with no items. We do this to rule out the possibility of specific items causing this issue.
  3. Set panel background to a JPEG with large dimensions, i.e. a 4k desktop wallpaper
  4. Benchmark FPS by running MANGOHUD=1 mangohud glxgears
  5. Remove panel background (set to solid color) and benchmark again
  6. Compare results
  7. Restore your ~/.config/xfce4

My test results

With the large JPEG panel background active 

297 frames in 5.0 seconds = 59.268 FPS
297 frames in 5.0 seconds = 59.127 FPS
296 frames in 5.0 seconds = 59.068 FPS
296 frames in 5.0 seconds = 59.002 FPS
293 frames in 5.0 seconds = 58.542 FPS
292 frames in 5.0 seconds = 58.278 FPS
295 frames in 5.0 seconds = 58.758 FPS
294 frames in 5.0 seconds = 58.783 FPS
292 frames in 5.0 seconds = 58.270 FPS
298 frames in 5.0 seconds = 59.318 FPS
296 frames in 5.0 seconds = 59.086 FPS
296 frames in 5.0 seconds = 58.998 FPS
299 frames in 5.0 seconds = 59.637 FPS
295 frames in 5.0 seconds = 58.631 FPS

Very interestingly we can see that it is markedly under the refresh rate of my 60hz monitor which I ran this test on, a few frames are just being eaten.

With just solid colour background active 

300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.997 FPS
301 frames in 5.0 seconds = 60.005 FPS
298 frames in 5.0 seconds = 59.404 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.001 FPS
300 frames in 5.0 seconds = 59.996 FPS
301 frames in 5.0 seconds = 60.005 FPS
301 frames in 5.0 seconds = 59.992 FPS

The problem disappears...

With a very large PNG

Works fine with large PNGs too, just not JPEGs.

300 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.001 FPS
300 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS

With a 10000x10000 JPEG

Not a realistic scenario, wallpapers are much smaller, just was curious.

285 frames in 5.2 seconds = 54.656 FPS
245 frames in 5.0 seconds = 48.997 FPS
286 frames in 5.0 seconds = 57.008 FPS
284 frames in 5.0 seconds = 56.798 FPS
284 frames in 5.0 seconds = 56.777 FPS
281 frames in 5.0 seconds = 56.041 FPS
277 frames in 5.0 seconds = 55.195 FPS
287 frames in 5.0 seconds = 57.394 FPS
287 frames in 5.0 seconds = 57.238 FPS

That is a very impressive drop.

Further information

  • It happens both with and without picom
  • The issue occurs when using both XFWM and Fluxbox
  • I tested both Xonotic and Team Fortress 2 and there are definite frame drops, in fact that's how I first discovered the issue
  • I wasn't able to match this issue to any noticeable increase in CPU/GPU/RAM usage