Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

eriefisher · 2026-08-05 15:12:47

Mod note:
Let's keep this thread civil please. Name calling and insults will get you removed from the forum.

daffyduck · 2026-08-05 23:31:51

LinuxStruggler wrote:

Nothing ever takes as little time as people online claim. And I already did a similar experiment, as you would've known if you had read my question instead of pushing more pointless busywork onto me.

Perhaps you did, but I don't see the results of the experiment stated clearly.
So, if you want help, state clearly how it went on other distros, and which distros you tried.

But suppose it does not happen on "some other distro". Then what? I need it fixed for the distro I actually use -- not some other thing.

Then you go to the distro's forums, because it is likely something they can fix.
If it works on one distro but not on the other, then it is likely distro's fault, not Xfce's.
So far, you provided no evidence to us that clearly show that you are experiencing an Xfce bug.

Moreover, I have multiple computers that contradict your results (which indicates that you are experiencing a distro bug). Why should we trust you, if you are not willing to even clearly state the results of the experiment ?

And how can it differ in the first place since they use the same software and drivers and everything?

Your assumption is wrong. Distros do differ a lot, and the difference between Arch-based, Ubuntu-based and Debian-based is significant.
No, they don't use the same driver versions. Nor do they use the same Linux kernel versions (which contains the drivers). So, you are wrong. And, everyone knows you are wrong, because those are all well-known facts.

LinuxStruggler · 2026-08-06 14:14:35

Test results:

Linux Mint (linuxmint-22.3-xfce-64bit.iso, hash-verified):

Laptop:
Desktop rectangle lagging behind cursor? YES.
Windows partially rendering/flashing when opened? YES.
Windows lag when moved around with the mouse? YES.

Old desktop:
Desktop rectangle lagging behind cursor? YES.
Windows partially rendering/flashing when opened? YES.
Windows lag when moved around with the mouse? "Kinda".

New desktop (main box):
Desktop rectangle lagging behind cursor? YES.
Windows partially rendering/flashing when opened? Not really, at least to a much lesser extent than on my installed Debian 13 on this box.
Windows lag when moved around with the mouse? Not really, but they also do not on my installed Debian 13 on this box.

NOTE: The Xfce desktop defaulted to being presented in 4k resolution, probably because my monitor and iGPU supports it and communicate this. There was no major difference in how the above experiments played out between 4k and 1080p (I tested both), though the desktop rectangle felt even more laggy in 4k mode. Also, curiously, Xfce seemed to get very confused when I tried to use the "2x scaling" option in 4k mode: normally, it scales everything 2x (sluggishly), but in this live environment, it just made everything look even smaller and fuzzier than 4k resolution. I tried it multiple times and the same thing happened each time. Very odd.

***

I'm not sure what conclusion to draw from this. It's not really clear-cut "Debian 13's fault". To me it still feels like there is a deeper "missing link" somehow related to drivers, but I've spent so much efforts on trying everything related to that for me to think that there's still something that can be configured/installed to fix this. Especially when the same things (roughly) happen on three different machines in good hardware condition and with the latest "live Linux Mint" environment.

I'll try to also check with MX Linux and EndeavorOS in the same manner over the next days.

Added later 01 min 16 s:

vm_x wrote:

I'm just posting this so you know I'm in your thread again, and can be whenever I choose to, and you can't do anything about it.

--snip--

Last edited by ToZ (2026-08-10 09:42:24)

eriefisher · 2026-08-06 14:27:10

Just out of curiosity and this may have been mention, I know one machine you tested is a laptop but are all of these connected to the same monitor? Possibly a hardware/monitor issue? KVM switch or cable?
It just seems odd that for the most part the same issue exist across hardware platforms.
If your going to try MX I suggest the AHS version. Apparently supports the newest hardware better.

daffyduck · 2026-08-07 02:24:10

LinuxStruggler wrote:

Test results:
Especially when the same things (roughly) happen on three different machines in good hardware condition and with the latest "live Linux Mint" environment.

Um... that could be the issue. You are using live Linux Mint environment to test it. It would be a much better test if you actually installed it (as non-live) on a second external USB stick.

Also, that's just ONE test: Debian and live Mint. You don't need to do all the tests with all the OS-es I mentioned, but given the two so far, I would also test it on live EndeavorOS and EndeavorOS installed on an external USB storage (as non-live). Note: I have never installed EndeavorOS in my life, I just know it is different, and it has good Xfce support.

I'll try to also check with MX Linux and EndeavorOS in the same manner over the next days.

As I have said, I think trying out multiple OS-es, with at least one "installed=non-live" is the best way to determine what is causing this bug.

MX Linux is essentially the same as Debian, although it offers multiple kernels if you install it. So, only with changing the kernel will you get some substantial differences from Debian. Kernel in MX Linux can be easily changed, they usually offer multiple kernel variants and versions.

Added later 35 min 20 s:
Also, regarding live installs:
Live installs are pretty limited. You can't update them, you can't change the kernel. If you go to complain on distro's forums, they would immediately dismiss you for testing on live media. Live media is mostly intended as a rescue tool, not as a rock-solid installation.

When you install the OS, you get the option to update it. Updating is the first requirement in order for you to be taken seriously anywhere.
Second, given the flickering / lag issue, which looks a lot like a driver issue, you are going to be directed to change to a newer kernel, on any forum.

Added later 51 min 14 s:
In both MX Linux and Linux mint you can change the kernel with a few clicks in the GUI (and then reboot). If you install Mint, to change the kernel, go to the Update Manager, then in the menu find and click on the "kernel" item.

JmaCWQ · 2026-08-07 09:28:14

Sometimes recommended on the MX forums is to try a live version if users are having troubles with an installed version that can't be easily solved.
It's also sometimes recommended to try out MX live on different hardware, for compatibility before purchasing etc..
With the default Live ISO's everything is at the MX team's agreed default settings, and is the 'complete' system.
There are some possible extra space requirements depending on how the ISO is running, USB, VM or whatever, but the live ISO's can usually be updated, but unless persistence is enabled any changes will be lost at shutdown.

EDIT: updating a live running system is quite handy for testing whether or not an updated version of something doesn't work correctly, among other things.

EDIT-2:

Live installs are pretty limited. You can't update them, you can't change the kernel. If you go to complain on distro's forums, they would immediately dismiss you for testing on live media. Live media is mostly intended as a rescue tool, not as a rock-solid installation.

Some live distros perhaps, but not all.
Some are designed fully functional, able to be installed across multiple machines, or able to be further customised via a 'snapshot' for backup or whatever.
And you won't get immediately dismissed for testing on live media and mentioning that on forums, as we all know complaining probably isn't the best way to approach a subject.
You are correct about not being able to change the kernel on a live ISO though, as far as I know anyway, but snapshots can be made with different kernels for testing or whatever purposes.

Last edited by JmaCWQ (2026-08-07 09:46:28)

LinuxStruggler · 2026-08-09 17:43:34

Here's the rest of the test results:

MX Linux (MX-25.2_Xfce_ahs_x64.iso, hash-verified):

Laptop:
Desktop rectangle lagging behind cursor? YES.
Windows partially rendering/flashing when opened? No.
Windows lag when moved around with the mouse? Yes.

Old desktop:
Desktop rectangle lagging behind cursor? YES.
Windows partially rendering/flashing when opened? No.
Windows lag when moved around with the mouse? "Kinda".

New desktop (main box, default 4k mode):
Desktop rectangle lagging behind cursor? YES.
Windows partially rendering/flashing when opened? No? (Doesn't seem like it.)
Windows lag when moved around with the mouse? No.

New desktop (main box, 4k mode with 2x scaling):
Desktop rectangle lagging behind cursor? YES!
Windows partially rendering/flashing when opened? No?
Windows lag when moved around with the mouse? No.

New desktop (main box, 1080p mode):
Desktop rectangle lagging behind cursor? Yes.
Windows partially rendering/flashing when opened? No.
Windows lag when moved around with the mouse? "Kinda".

(MX Linux used a very modified/nonstandard Xfce setup/theme. Very strange distros.)

EndeavorOS (EndeavourOS_Titan-Neo-2026.04.27.iso, hash-verified):

EndeavourOS turned out to not use Xfce anymore, but Plasma (and no option to change), so I didn't bother checking it except for on the old desktop (where I noticed it). I tried the desktop selection rectangle thing anyway and it was *super laggy* on there (much worse than on Xfce), with the "open source drivers" (default) option. With the secondary "Nvidia drivers" option, it was the same, but also used a strange, nonstandard resolution.

Added later 01 min 01 s:

eriefisher wrote:

Just out of curiosity and this may have been mention, I know one machine you tested is a laptop but are all of these connected to the same monitor? Possibly a hardware/monitor issue? KVM switch or cable?

No, they are completely different monitors with different cables.

Added later 05 min 33 s:

daffyduck wrote:

You are using live Linux Mint environment to test it. It would be a much better test if you actually installed it (as non-live) on a second external USB stick.

I didn't know that there would be any difference. That sounds strange to me.

daffyduck wrote:

When you install the OS, you get the option to update it. Updating is the first requirement in order for you to be taken seriously anywhere.

Why is updating needed when I downloaded the latest ISOs just before installing them? It's not like I had years-old sticks with these live systems just lying around?

daffyduck wrote:

Second, given the flickering / lag issue, which looks a lot like a driver issue, you are going to be directed to change to a newer kernel, on any forum.

Surely they don't put old kernels on live distributions? In fact, I'm not even sure they are called special "live" versions, but rather they start up and let you install the OS from within them (unlike Debian, by the way).

deleted_08102026 · 2026-08-10 08:36:08

LinuxStruggler wrote:

--snip--

--snip--

Added later 1 h 20 min 16 s:
Well, okay, ToZ decided he wants to build this community around "people" like OP, so delete my account please.

Last edited by deleted_08102026 (2026-08-10 09:58:22)

daffyduck · 2026-08-10 10:19:31

LinuxStruggler wrote:

Here's the rest of the test results:
EndeavourOS turned out to not use Xfce anymore, but Plasma (and no option to change), so I didn't bother checking it except for on the old desktop (where I noticed it). I tried the desktop selection rectangle thing anyway and it was *super laggy* on there (much worse than on Xfce),

Well, if you have the same error on Plasma too, then it is unlikely to be Xfce's fault.

with the "open source drivers" (default) option.

Open source drivers for GeForce lack the ability to "reclock" the GPU, for many GPU models. That means your GPU always stays at the lowest (slowest) clock speed. That can cause lag on high resolutions.
Depending on which GPU models you have (and which kernel), reclocking could be supported or not.

With the secondary "Nvidia drivers" option, it was the same, but also used a strange, nonstandard resolution.

It is therefore important that you either assure the "reclocking" is supported, or use proprietary nVidia drivers.

Why is updating needed when I downloaded the latest ISOs just before installing them? It's not like I had years-old sticks with these live systems just lying around?

Those "latest ISOs" can be up to two years old, depending on the distro. It is assumed that you will update it.

Surely they don't put old kernels on live distributions?

As I have said, ISO could be old itself. Regarding the kernel, usually it is some newer kernel, with low patch number, i.e. the most buggy kernel would be usual on the ISO.

LinuxStruggler · 2026-08-14 14:21:35

The "MX-25.2_Xfce_ahs_x64.iso" file I used, listed in https://sourceforge.net/projects/mx-lin … inal/Xfce/ says "2026-05-24", which is just a couple of months old. I think we can exclude the possibility that it's "too old".

And yes, the sluggish selection rectangle also happens in Plasma, but I already knew that much. It's one of the reasons I swore to never again waste my time on Plasma after spending two years on it trying everything to make it work properly.

What should be more interesting is the fact that I can't seem to notice the partially drawn windows on the main box where it truly matters. Seems clear that it's not "my hardware" at fault.

Anyway, I'm completely exhausted at this point and don't have any more things to try. Using my computers is literally torture with these fundamental UI glitches, but I've gone beyond what any sane person would in order to try to solve it yet failed. Neither documentation, humans nor LLMs have been able to help me, and I've tried so many random things in desperation over many fresh installations now that I'm out of ideas and the will to continue.

It wasn't a choice for me to switch to Linux, but a necessity. Windows no longer exists as an OS and simply cannot be run, macOS has equally become spyware, and anything other than Linux is infinitely more obscure and problematic. It's either putting up with a completely broken UI and constant "flashbangs" (I didn't even include the Firefox issue in my tests because it's clearly related to the others) or not using a computer at all, so I guess I have no choice at this point but to wait for Debian 14 and hope that it has magically fixed this and not introduced something worse.

And before you say it, no, using MX Linux isn't an option. I barely trust Debian, a core/"real" distro, and so much code and mechanisms and installation instructions are customized to Debian that switching to any other Linux distro (even if it had been possible) would be a monumental task. I wanted to figure out the root cause and fix it -- not be pushed again into some other corner with other issues resulting from it.

Last edited by LinuxStruggler (2026-08-14 14:23:54)

Blacklight · 2026-08-15 00:33:41

Gnu/linux is nothing like an OS, you get at the store preinstalled on a computer. Those computers are put together by a parallel effort to make those proprietary OS, and the hardware serve each other.

When you're putting Gnu/Linux on a regular consumer PC, with consumer PC hardware/peripherals you are working with a system, that is besides all of those intentions, that went into making the systems you are trying to work with.

The first thing you should realize, is that you will never get the same kind of support, for your hardware, as proprietary systems do. You may actually have to wait years, for Gnu/linux to support a feature you paid for on your system for example. It's that severely different.

It's a completely different universe, than proprietary land. What is great about the situation, is that you have meaningful control over it, confronted with issues, compared to the alternative situation, where you have basically no control.

If you ran trixie 13, on an xfce live cd (https://cdimage.debian.org/debian-cd/cu … 4-xfce.iso) (which is probably the best thing in the universe btw) then you should have been able to tell immediately, if you had a graphical issue.

The installs are also different, depending on the method. I would first, just use a different method. Always do installs offline, that always leads to a consistent, reliable, stable system. Always do your installs offline. Always dd the iso properly to a cleanly repartitioned, and formatted usb. Always sync it at the end. Always disconnect the computer from the internet, for the install, and the initial reboot, and turn off as many automatic services as you possibly can identify, that you don't need.

Debian-Xfce is a rock solid choice. If you go to a wayland based or kde based distro you will have extreme bugs. Nothing is more stable than debian+xfce, (except rarely xfce fedora/cent-os types) but it takes a little extra effort to make it work nicely out of the box. Start with the live CD, start with a solid, stable installation, and configure the whole system from the ground up.

You have brand new hardware, so you may just have to learn how to upgrade your kernel outside of apt package management, and configure your system properly, to get everything working as expected.

Added later 23 h 35 min 24 s:
There's quite a lot to add here actually

I'm not sure how much time you have... (to talk about all the ways to improve your systems performance with Gnu/Linux)

The most important thing you can do, which no one will explain to you: is to disconnect your computer from the internet -> load the live cd (debian-xfce) -> press tab or e on the keyboard to show the boot commands, and where it says "quiet" -> delete "quiet" and enter in cpufreq.default_governor=performance

By default, Gnu/Linux is running your CPU in powersave, slowwwww, mode. No one will explain any of these things to you. Turn your cpu to performance mode -> do your proper stable install -> leave it disconnected -> reboot(poweroff) -> then start tweaking everything you can find to improve performance, and you will never have lag/issues again.

Add cpufreq.default_governor=performance to /etc/default/grub by default, delete quiet, and enter that command. save the file, sudo update-grub

turn off as many services as you can identify, that you don't need, and automatic startup programs.

Then, one final thing, don't reboot. Never reboot. -> Always power off. Open a command line, and manually type in sudo poweroff

don't type in shutdown, because it doesn't mean the same thing as poweroff. There's so many details, and so much complexity, it is laughable.

Then, when the system is off, and wrrrrr silent. When everything comes to a complete halt. Wait, don't act, just wait. Take a deep breath. Give the machine time, to relax.

Then, connect it back to the internet -> and reboot into the best system you will ever use in your life.

(you should also delete "splash" from the grub command line -> and when you follow my instructions, and your Gnu/Linux system starts up and shuts down, instantly over and over without interrupts, or slow downs, and your system performs perfectly and consistently, you will know, that all of these weird little details, saved the day.)

(you wont even see a splash ever again, or any commands flashing on the screen -> because now, you will have a perfect, stable system)

(don't forget)

Last edited by Blacklight (2026-08-16 00:59:58)

gogogadget · 2026-08-16 09:01:54

Blacklight wrote:

By default, Gnu/Linux is running your CPU in powersave, slowwwww, mode

It's not slow, because by default the kernel use the intel_pstate driver, in this case the governor is more balanced and has nothing to do with the usual powersave one. And if it was in the real powersave mode, I don't see an I9 14900 unable to run Xfce smoothly.

Blacklight · 2026-08-16 13:58:46

intel_pstate is a part of the CPU performance scaling subsystem in the Linux kernel (CPUFreq). It is a scaling driver for the Sandy Bridge and later generations of Intel processors. Note, however, that some of those processors may not be supported. [To understand intel_pstate it is necessary to know how CPUFreq works in general, so this is the time to read CPU Performance Scaling if you have not done that yet.]

CPUFreq provides generic scaling governors that can be used with all scaling drivers. As stated before, each of them implements a single, possibly parametrized, performance scaling algorithm. ... When attached to a policy object, this governor causes the highest frequency, within the scaling_max_freq policy limit, to be requested for that policy.
The request is made once at that time the governor for the policy is set to performance and whenever the scaling_max_freq or scaling_min_freq policy limits change after that.

TLDR use cpufreq.default_governor=performance

Actually it's important to do so, for high performance hardware, or you will have issues. It's actually meant to be run at high performance states, and not in slow mode. (which is the default) It will affect the performance of all aspects of the system.

To check it, you can do: sudo cat /proc/cpuinfo | grep MHz

You should be looking at your highest clock speeds for your cpu's - if your system is configured correctly.

https://www.kernel.org/doc/html/latest/ … state.html

https://www.kernel.org/doc/html/latest/ … ufreq.html

Last edited by Blacklight (2026-08-16 14:04:28)

gogogadget · 2026-08-16 14:41:58

Blacklight wrote:

Actually it's important to do so, for high performance hardware, or you will have issues.

Which one ? Because I don't see the point of having a mode that is buggy.

From your first link :

For example, the powersave P-state selection algorithm provided by intel_pstate is not a counterpart of the generic powersave governor (roughly, it corresponds to the schedutil and ondemand governors).

powersave will increase the frequency when needed and I don't think everybody want their computer to always be on high frequency, it's just consuming power for nothing.

My Rizen is working more or less the same :

driver: amd-pstate-epp
hardware limits: 636 MHz - 5.28 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 1.97 GHz and 5.28 GHz.
The governor "powersave" may decide which speed to use
within this range.

powersave can go to the max frequency if needed.

Blacklight · 2026-08-16 15:50:39

Actually the way it works, is that your cpu will not consume more power, just because it is on a higher frequency setting. It will only consume more power when more work is required of it.

Instead it will just perform faster, and more effiiciently by default, when work is required of it. That's what performance means as opposed to powersave.

(with powersave, hopefully, but not typically, it will change itself to a higher performance state, but actually it will do so very rarely, such as during a kernel compilation, where all the cpu threads are called upon to build the kernel)(otherwise you may just have one or a few threads that get up into higher frequencies)(and up or down variably - as opposed to max speed all the time)(slowww mode)

Try it out for yourself.

sudo cat /proc/cpuinfo | grep MHz

Append cpufreq.default_governor=performance (in /etc/default/grub)

to your grub command line, reboot and check it again

sudo cat /proc/cpuinfo | grep MHz

The cpu's performance sits at the heart of the rest of the systems performance, which will differ based on it's total configuration. That's why I recommend, to actually start New, and configure the system - 'from the ground up'

The graphical performance is dependent on the CPU's performance to begin with. If the the cpu is lagging behind, then the graphics will suffer. First comes the CPU -> then the rest of the system.

If users even fail to install the system correctly, they will have performance issues. There is actually a lot of complexity involved. That's why I gave the advice I did, towards actually creating a stable base to begin with. Even sitting around waiting for some buggy systemd function that appears when starting up / shutting down, is an interrupt for the user, a detriment to system performance.

Instead of just using their computer, most people sit around staring at loading screens(or slow/buggy UI); with a little extra effort, and knowledge, that can be completely avoided.

You also don't have to query /proc to see that it's the case, when you have a slow/buggy GUI, as the OP is describing, with high end, high performance hardware/peripherals, you can simply SEE that's it's true.

Last edited by Blacklight (2026-08-16 15:57:13)

gogogadget · 2026-08-17 18:05:05

Blacklight wrote:

Append cpufreq.default_governor=performance (in /etc/default/grub)
to your grub command line, reboot and check it again

Not needed, one command as root is fine :

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

I noticed both modes have the same frequency range and when I stress the CPU, the cores/threads in both modes go immediately to 100%. I guess the performance mode might be more responsive or better at dealing with energy efficiency in some cases

Last edited by gogogadget (2026-08-17 18:06:04)

Xfce Forum

Sub domains

#26 2026-08-05 15:12:47

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#27 2026-08-05 23:31:51

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#28 2026-08-06 14:14:35

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#29 2026-08-06 14:27:10

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#30 2026-08-07 02:24:10

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#31 2026-08-07 09:28:14

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#32 2026-08-09 17:43:34

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#33 2026-08-10 08:36:08

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#34 2026-08-10 10:19:31

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#35 2026-08-14 14:21:35

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#36 2026-08-15 00:33:41

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#37 2026-08-16 09:01:54

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#38 2026-08-16 13:58:46

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#39 2026-08-16 14:41:58

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#40 2026-08-16 15:50:39

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#41 2026-08-17 18:05:05

Re: Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

Board footer