Raspberry Pi 4B – Performance issues with XFCE

Hi,

I have an issue with XFWM window manager's performance on Manjaro XFCE – it seems to work laggy or buggy, depending on settings of the compositor. I tried set that to fix my framerate:

  • turning off shadows – no effect or framerate gain and the OS still seems laggy;

  • turning off compositor – seems faster, but really buggy when fast moving or resizing windows, especially those "heavier" (windows move slower than cursor and have "ghost" effect);

  • hiding windows content when moving and resizing windows with turned on compositor – no effect compared to a setting with compositor;

  • hiding windows content when moving and resizing windows with turned off compositor – most stable and reliable option now, seems to work fine as it should;

  • turning on compositor and changing vblank_mode to xpresent (glx is default) – seems "the fastest" option and the closest to the one working fine, but for now it's really buggy (windows are often flickering/tearing when it's content/position/size changes);

  • turning on compositor and setting vblank_mode value to off – has similar effect to turning off compositor but without annoying "ghost" effect; however hiding window content isn't here a solution and doesn't change much with performance (or at least I can't feel it). Also, in my opinion, this is one of the options I would set on my Raspberry Pi.

So it seems that the problem itself is with vblank_mode setting. Also, I don't think it's performance issue with CPU, it might be however GPU performance issue. However please note I don't have any issues with XFWM on Raspbian, which seems to be older, but works more stable and faster.

As for my settings, I've only added this entry in my cmdline.txt: usbhid.mousepoll=0, but I don't think that's an issue – it fixes an issue with my mouse on most OSes on Raspberry Pi (even on NOOBS or PINN), so I rather would like to have it set. Also I didn't overvoltaged on my Pi, but I overclocked it's processor frequency 1600 MHz (I know it doesn't change much with performance, but it's free so why not use it), but this problem persist without any overclocking options set. I also didn't overclocked my GPU, but I set my gpu_mem value to 512MB (I've got a version of Pi with 4GB in total of random-access memory).

Is there any option I could try to make my XFWM yet faster/stable/glitchless? Am I only encountering this problem?

Regards,
SpacingBat3

I would say try switching the compositors mode
New xfwm compositor has 2 modes - 'glx' and newer 'xpresent'
On AMDGPU you must switch to xpresent for good performance.. maybe similar for you?

xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "xpresent" --create

EDIT - looks you did that already and I skipped that one. oops.

You can also try replacing default compositor with picom
https://wiki.archlinux.org/index.php/Picom

https://wiki.manjaro.org/index.php?title=Using_Compton_for_a_tear-free_experience_in_Xfce
(this page is relevant .. but compton is no more and this page should be replaced with successor picom)

Thanks for answer,

It seems a some kind of fix, but at first picom also seemed to work the same as XFWM4 default compositor (when comparing both launched with "glx setting").

However, launching it with xrender backend seem to work here like in situation, when I turned off vblank_mode while turning on XFWM compositor – it's seems however working faster, that fast as windows mostly align to cursor properly. However when moving windows for quite fast and long time it will also be moving with visible delay after cursor movement. So it seems that glx backend is pretty broken with raspberry pi's graphics acceleration.

I just started playing with picom and I discovered that with glx backend shadows and transparency were enabled, unlike with xrender – when running without any config I just got all of these stuff disabled and I'm not sure if they're going to work, but I wouldn't be suprised if they don't. So this method isn't perfect for me, however maybe the best I could try.

I'm also still curious why then it worked fine on Rasbian with xfce4 environment installed without any issues? Were just packages better supported? Or XFWM started to be more resource-hungry with newer release?

I've got an idea to switch back to Raspbian and check out if it's going to work with turned off compositor – maybe there's no problem with it, but with the XORG settings itself. Also, I'm gonna try run it with different vblank_mode setting.

xfce is definitely heavier than it was.
And its compositor has always been ... a point of annoyance.
(and because of that it was one of the things somewhat recently overhauled..)
But to see regression could be any number of combinations.. could be the kernel or mesa version.
Or .. gasp .. it could be manjaros fault .. but thats no more likely than any given single package with a different version number.

I havent been playing with the ARM things so maybe someone else will have a better idea :slight_smile:

1 Like

Ok, I've already found the fix for myself, and I'm posting it for people that might came out with similar problems on RPI_4B (overall os performance issues with Manjaro ARM).

I checked how Pi (and most importantly: my mouse :slight_smile:) would behave with higher values of usbhid.mousepoll and I discovered that with higher values the performance noticeably increased. When I set usbhid.mousepoll to 8, I were able to use Manjaro still without compositor, but with content visible when moving/resizing windows.

(Un)fortunately, my mouse broke a little and I decided to buy another. I discovered it's working well on default usbhid.moisepoll setting. Now I checked how Manjaro XFCE will run under compositor, and... it were quite well, but still with vblanc set to off, and it were still quite imperfect as it slowed down OS performance a bit. So turning compositor off is still recommended at current state.

As I see I'm not the only one having problems with performance (see this thread).

Anyway, that could be a potential fix for everyone that has issues with Manjaro's performance as I saw many people just set this kernel option to zero on their Pi. As conclusion, I would never set usbhid.mousepoll=0, but rather usbhid.mousepoll=8 or with bigger value (eight is default on Linux X86, but it doesn't seems to on Raspberry Pi Linux kernel). Even values like 2 or 1 are better than zero, and I've also get a higher performance with them. So I suggest playing with this option if you want great performance.

It also the case of other OSes on the Raspberry Pi 4B, not only Manjaro (even Raspberry Pi OS seemed to be faster than ever when I removed usbhid.mousepoll from my cmdline.txt).

Anyway, thank you, @cscs. I really appreciate your help as it were quite useful to investigate the problem source and possible options to fix this issue.

Regards,
SpacingBat3

4 Likes

Well finally it is looking that usbhid.mousepoll= may be the answer to this issue. Your post had me do some researching today. It seems that some mice are requesting it's default polling rate when the linux default is used (usbhid.mousepoll=0). This seems to make some mice not play well using it's default poling rate. I was at a loss when I was not having an issue (as well as some others) and some had issues.

I added usbhid.mousepoll=8 to my cmdline.txt and my mouse seemed to work even better on my Mate install.

Starting with the next new kernel package I make I will add it to the cmdline.txt.

Of course disabling the Compositor is recommended.

Here what a RPi Engineer had to say:

I believe the number is the interval in milliseconds to poll the mouse at. Zero is special meaning use the number the mouse requests (i.e. the original linux default).
The new default will be the higher of 16, or what the mouse reports.

You if you want to set a compromise value, I'd suggest trying 8, or 4.

I turned off compositors on XFCE4 and i3 only Manjaro Plasma works ok after installation.
I had also problems with mouse however I have few of them so I use that one what works.

I do not believe adding usbhid.mousepoll=8 to /boot/cmdline.txt and rebooting will not hurt being there but in theory as I understand it all of your mouses should work good instead of a select few. You could test and see if the assumption is correct. I do not have many mouses.

Forum kindly sponsored by