Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

LinuxStruggler · 2026-06-18 18:47:49

(Full title: "Inexplicably sluggish and glitchy rendering of basic desktop UI elements.")

I run Debian 13 with Xfce. The PC has an "Intel Core I9 14900 LGA 1700" CPU with a "UHD Graphics 770" iGPU. There is no dGPU.

I have no other hardware-related problems or issues with performance; it is solely related to Xfce's rendering/drawing of the basic GUI elements such as windows. Things like displaying a 3D world-globe with a bunch of layers and effects is smoothly rendered inside a desktop application using NW.js (Chromium webview), so there is no fundamental issue with the iGPU nor with Linux's ability to use it. It somehow only affects Xfce itself.

I recently reinstalled it from scratch in order to ask this question "cleanly":

1. Immediately, the default, native 4k resolution mode is completely unusable, whether in "2x scaling" mode or not. Videos "tear" when the camera moves sideways, scrolling text on webpages wobbles, selection rectangle is extremely sluggish, etc.
2. I'm forced to use 1920 x 1080 px resolution in order to be able to use the computer at all, which I have at this point just accepted as "necessary on Linux". But even this has extremely annoying issues:

* Opening any application, its GUI window is very noticeably *partially* drawn before being fully "solid", appearing like an annoying glitchy "flash" to my eyes. I have recorded my screen with OBS and then looked at the resulting video in slow-motion to verify this: the "partial" render includes the "title bar" and the "borders" on left, right and bottom, with the "main rectangle" being transparent and showing what's underneath it (for example the wallpaper). Only in the next frame does it render fully.
* Firefox and various other programs like to randomly throw at me bright "flashbangs" when opening, closing or clicking on things within the program, or sometimes when switching to it from viewing something else.
* Absurdly sluggish selection rectangle on the desktop (the cursor is perfectly responsive but the rectangle very noticably does not "keep up").
* A general feeling that "something is off" about the GUI rendering, the same kind of feeling I had in the early 2000s each time I reinstalled Windows XP, prior to downloading the special GPU drivers.

The monitor is a modern "Samsung ViewFinity S27D800E", its firmware recently updated, and even uses a new DisplayPort cable. 60 Hz is selected and there's nothing above it. Setting it to other Hz settings causes even worse problems.

X11 (just to be clear).

I have tried *countless* things suggested by people and LLMs to fix this, but nothing helps. In fact, most things make it even worse.

* Running `grep -E "modeset|intel" /var/log/Xorg.0.log` right after installation revealed that it was using "intel" and not "modesetting" mode by default.
* Like the Debian manual told me, I removed the `xserver-xorg-video-intel` package and rebooted. Now that same command says "modesetting", but the desktop drawing performance is the same as before, or possibly slightly *worse*.
* I tried to re-install the `xserver-xorg-video-intel` package, but even after rebooting, it still continues to say "modesetting" (not "intel"), so I can't even get it back to the initial (bad) mode.

I've tried all four of the "vblank" modes:
`xfconf-query -c xfwm4 -p /general/vblank_mode -s "auto"` <-- Default and what I currently use.
`xfconf-query -c xfwm4 -p /general/vblank_mode -s "off"`
`xfconf-query -c xfwm4 -p /general/vblank_mode -s "glx"`
`xfconf-query -c xfwm4 -p /general/vblank_mode -s "xpresent"`

All the other three just cause severe glitchiness when scrolling or other issues.

As per LLM advice, I've previously tried numerous things like this: making the file `/etc/X11/xorg.conf.d/20-intel.conf` with contents such as this:

	Section "Device"
	    Identifier "Intel Graphics"
	    Driver "intel"
	    Option "TearFree" "true"
	EndSection

In the non-"modesetting" ("intel") mode (the installation default), it *did* fix specifically the screen tearing for videos in 4k mode, *but* caused even worse performance for everything else, making it useless. When I tried the same thing but in "modesetting" mode, Xfce refused to start at all. I had to delete that file again to restore Xfce's ability to start.

Please don't tell me to "turn off the compositor". I've done it countless times without improvements, but even if it did work, it still couldn't be left like that because when you turn off the compositor in Xfce, it for some reason ignores the GTK.css rules, which makes me unable to get rid of the extremely annoying "tooltips" which make it unbearable to use.

`lspci -k | grep -EA3 'VGA|3D|Display'` says "Kernel driver in use: i915".

`sudo glxinfo -B` says "direct rendering: Yes" and "OpenGL renderer string: Mesa Intel(R) Graphics (RPL-S)".

`grep -iE 'loaded.*(intel|modesetting)|using driver|glamor' /var/log/Xorg.0.log` outputs:

[    16.525] (II) Loading sub module "glamoregl"
[    16.525] (II) LoadModule: "glamoregl"
[    16.525] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[    16.530] (II) Module glamoregl: vendor="X.Org Foundation"
[    16.673] (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) Graphics (RPL-S)
[    16.673] (II) modeset(0): glamor initialized

`uname -r` says "6.12.90+deb13.1-amd64".

`xfwm4 --version` says:

        This is xfwm4 version 4.20.0 (revision unknown) for Xfce 4.20
        Released under the terms of the GNU General Public License.
        Compiled against GTK+-3.24.43, using GTK+-3.24.49.
 
        Build configuration and supported features:
        - Startup notification support:                 Yes
        - XSync support:                                Yes
        - Render support:                               Yes
        - Xrandr support:                               Yes
        - Xpresent support:                             Yes
        - X Input 2 support:                            No
        - Embedded compositor:                          Yes
        - Epoxy support:                                Yes

`dpkg -l | grep xfwm4` says "4.20.0-1".

I've tried setting various "kernel boot flags", also from LLM/human advice. Makes zero difference.

A little while ago I tried putting Fedora-Xfce-Live-43-1.6.x86_64.iso on a stick and booted into it on the same machine. The desktop rectangle is still laggy in both 4k, 4k + 2x scaling, and even 1080p. So it's not Debian's fault.

I had even worse issues with KDE/Plasma, and I've "DE-hopped" a lot in desperation but all other Linux DEs are even worse than Xfce. I no longer have the energy to switch to something else even if it existed. I just want Xfce to work properly.

I've tried "random advice" for so long which each time gets my hopes up, only for the problem to persist. Please let there be some simple solution that I've missed.

eriefisher · 2026-06-18 19:36:48

Have you tried i915.force_probe=4680? It's older but still maybe needed.

References:
https://cateee.net/lkddb/web-lkddb/DRM_ … PROBE.html
https://www.phoronix.com/review/uhd-graphics-770

LinuxStruggler · 2026-06-23 01:20:50

eriefisher wrote:

Have you tried i915.force_probe=4680?

No, I had not that tried that one as far as I can remember, but I did today. To be clear, I did exactly this:

`sudo nano /etc/default/grub`

Changed:
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
into:
GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.force_probe=4680"

And then I ran `sudo update-grub` and rebooted.

No difference whatsoever...

This is just too absurd for words. And not a single person (or LLM) in the world can apparently find the cause/fix. What the hell could be causing this? I'm years into using Linux full-time now and it's just been one long nonstop debug session. Particularly the basic drawing of the GUI seems to have extreme, fundamental issues no matter the GPU/distro. I truly don't understand how this can be.

I'm reverting the change again.

LinuxStruggler · 2026-07-08 20:11:01

Some updates.

1. I also tried this with the same procedure as above, again with no improvement: `GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.enable_psr=0 i915.enable_fbc=0"`

2. I also tried installing "picom" as an "alternative compositor".

I first ran `xfconf-query -c xfwm4 -p /general/use_compositing -s false` to turn off the built-in Xfce compositor. I then ran `picom --config ~/.config/picom.conf` and it INITIALLY seemed to work, with Thunar opening without "partial drawing". I got my hopes up. Though the other issues (laggy desktop selection rectangle, Firefox flashbangs, etc.) did not resolve.

I made it start on boot by creating `~/.config/autostart/picom.desktop` with the contents:

[Desktop Entry]
Type=Application
Exec=picom
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=picom

HOWEVER, for some reason, it stopped working at some point, and ever since, in spite of trying many variations of the config options (and a minimal config), with no rhyme or reason, it just doesn't work consistently/at all. I truly don't know what to make of this. I've verified that picom actually runs and that the built-in compositor is disabled, so it's not that.

I tried all of `backend = "glx";`, `backend = "xrender";`, `backend = "dummy";`, `backend = "egl";`, etc., with and without `vsync = true;` and a bunch of other options. No difference. It's like nothing I try ever makes it run properly. It's maddening beyond words.

3. I have bought a laptop, partially for the sake of trying this. It's a "Lenovo ThinkPad E14 Gen 6 - Ryzen 7". It has some Radeon GPU. I installed latest Debian 13 on it with Xfce. Guess what? Even on it, the damn selection rectangle on the desktop lags behind the cursor, and Thunar/windows open "partially" on there too! (Not sure about the flashbangs in Firefox. It's not fully set up yet.)

If it weren't for the fact that I've briefly and in the past and in certain contexts seen with my own eyes that Xfce can open windows without partially drawing them in that ugly manner, even on the main computer "when it feels like it", I would at this point simply conclude that Xfce is fundamentally broken just like Plasma and every Linux GUI.

With three different modern computers all having random issues related to laggy selection rectangles and drawing basic UI elements, even on default installations with no weird configs, I don't know what to think at this point. Have I gone insane? Do you all not experience the same things? Do you just not care? What is the real explanation?

LinuxStruggler · 2026-07-10 15:43:35

I can't function like this. Every moment I'm using my computer is just torture this way. I don't understand how it's possible. But I already know (as I've mentioned) that there is nothing better than Xfce, so I need to somehow figure out what the hell is causing this.

This cannot be some super-rare coincidence of unsupported hardware at this point. Are you all really not experiencing the same thing?! Don't you have any ideas? This has become like Chinese water torture to me: constantly frustrating me and I'm never "getting used to" it.

ToZ · 2026-07-10 16:53:40

Its strange that you are having this issue as the UHD 770 should be supported on that kernel version.

Do you have the intel-media-va-driver-non-free and firmware-misc-nonfree packages installed (using the modesetting driver)? The former for hardware accelerated video and the latter for required firmware?

Could you post a complete Xorg log file output as well as the output of the xrandr command?

LinuxStruggler · 2026-07-14 19:06:48

ToZ wrote:

Its strange that you are having this issue as the UHD 770 should be supported on that kernel version.

It certainly is strange to say the least.

ToZ wrote:

Do you have the intel-media-va-driver-non-free and firmware-misc-nonfree packages installed (using the modesetting driver)? The former for hardware accelerated video and the latter for required firmware?

`apt search intel-media-va-driver-non-free` returns nothing, and neither does `apt list --installed | grep intel-media-va-driver-non-free`. I also tried `apt search intel-media-va-driver-nonfree` in case you made a typo, but nothing returned for that either.

However, "intel-media-va-driver" (without the "-non-free" in the end) does exist, and is installed.

As for "firmware-misc-nonfree", it does exist but isn't installed. (And this is the first time I ever hear of it that I can recall.) Should I install that?

ToZ wrote:

Could you post a complete Xorg log file output as well as the output of the xrandr command?

Here you go:

xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 HDMI-1 disconnected (normal left inverted right x axis y axis) HDMI-2 disconnected (normal left inverted right x axis y axis) DP-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 3840x2160 60.00 + 30.00 29.97 2560x1440 59.95 1920x1080 60.00* 50.00 59.94 1680x1050 59.95 1600x900 60.00 1280x1024 60.02 1440x900 59.89 1280x800 59.81 1280x720 60.00 50.00 59.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.00 59.94 640x480 60.00 59.94 HDMI-3 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) HDMI-4 disconnected (normal left inverted right x axis y axis)

/var/log/Xorg.0.log:

"Posts cannot be longer than 65,535 characters."

I couldn't think of any other way to post this than using a pastebin: https://pastebin.com/raw/bHGHnSba

ToZ · 2026-07-15 01:10:09

I'm not that familiar with Debian. On Arch, there is a package called "linux-firmware-intel". It appears that is might be this package on Debian.

Is the newer intel xe driver available for your card? If you run:

lspci -vnn | grep -A10 VGA

...do you see something like this?

	Kernel driver in use: intel
	Kernel modules: i915, xe

If so, the xe driver is an option but not enabled. Given that you have such a new video card, it might be worth giving the xe driver a shot.

.

To do so, you first need to get the hardware ID of the card. The above command should show it. On my system:

00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller])

...the ID is the second half of 8086:9a49, so "9a49".

Then, to test it, when you are booting into your system, press the edit key at the grub or systemd-boot screen to edit the linux command by adding the following to the string:

i915.force_probe=!9a49 xe.force_probe=9a49

...and change 9a49 to match your specific ID.

Once booted, you can check if it took effect via:

cat /proc/cmdline

...or run the lspci command from above to see something like:

	Kernel driver in use: xe
	Kernel modules: i915, xe

I believe you will also need that firmware package installed prior to doing this.

On my older TigerLake system, this nets me about a 15% performance improvement.

If this still doesn't work, can you post the output of the following after a fresh reboot?

sudo journalctl -b 0 --no-pager

LinuxStruggler · 2026-07-15 16:36:38

ToZ wrote:

I'm not that familiar with Debian. On Arch, there is a package called "linux-firmware-intel". It appears that is might be this package on Debian.

Yes, I have that "firmware-intel-graphics" package installed, and that clearly happens by default on Debian (because I haven't installed it manually).

ToZ wrote:

If you run:
lspci -vnn | grep -A10 VGA
...do you see something like this?
	Kernel driver in use: intel
	Kernel modules: i915, xe
If so, the xe driver is an option but not enabled. Given that you have such a new video card, it might be worth giving the xe driver a shot.

It says for me:

        Kernel driver in use: i915
        Kernel modules: i915, xe

...

I did what you said (my value is "a780") and put "i915.force_probe=!a780 xe.force_probe=a780" after the "quiet " part when in the "e" menu in the boot loader, then pressed F10 to boot.

`cat /proc/cmdline` now says: "BOOT_IMAGE=/vmlinuz-6.12.95+deb13-amd64 root=/dev/mapper/Towery--vg-root ro quiet i915.force_probe=!a780 xe.force_probe=a780"
`lspci -vnn | grep -A10 VGA` says:

Kernel driver in use: xe
Kernel modules: i915, xe

Yet the same damn issues remain, as if nothing had changed at all. Just like so many times before when I've tried similar things. It's surreal. I seriously start to get thoughts like my hardware is being intercepted when I order it home, modified in some way just to mess with me psychologically...

ToZ wrote:

If this still doesn't work, can you post the output of the following after a fresh reboot?
sudo journalctl -b 0 --no-pager

Well, it contains an enormous amount of sensitive private information, making it impossible to share as-is. Is there anything in particular you want me to report from it?

vm_x · 2026-07-15 21:43:35

So you have these same issues on three different and completely unrelated computers?

ToZ · 2026-07-15 22:42:51

LinuxStruggler wrote:

Well, it contains an enormous amount of sensitive private information, making it impossible to share as-is. Is there anything in particular you want me to report from it?

Anything graphics related or errors would be of interest.

Yet the same damn issues remain, as if nothing had changed at all. Just like so many times before when I've tried similar things. It's surreal. I seriously start to get thoughts like my hardware is being intercepted when I order it home, modified in some way just to mess with me psychologically...

I think its just something that hasn't been identified yet. Have you tried with a different monitor and/or connector/cable?

LinuxStruggler · 2026-07-16 22:20:23

vm_x wrote:

So you have these same issues on three different and completely unrelated computers?

Well, ignoring all the messy history and focusing only on the current situation, it's like this for the three computers I have now (all run Debian 13 and Xfce installed right from the installer; no "exotic custom weirdness"; fresh experiments made today):

Box #1 (HP workstation, Nvidia dGPU, bought 7 years ago, old Dell monitor):
1. Desktop selection rectangle lags behind cursor.
2. Windows open with a small perceived "flash", especially when it is specifically the Wastebin being opened. Because there is some persistent major network issue with installing packages, I could not install and record the screen with OBS, so instead I physically filmed the screen while I opened windows and then watched the video frame-by-frame. When a normal dir on the desktop is double-clicked, Xfce seems to open without a flicker, but when the Wastebin is double-clicked, it consistently shows one frame where only the "chrome" of the window is rendered, with the main canvas being completely "see-through", and the icon in the top-left corner is some kind of generic placeholder "window icon" before it switches to the Wastebin icon in the next frame when the window contents are also rendered.
3. I could not replicate the flashbangs in Firefox ESR, so maybe that is a separate issue, or I was just "lucky" this time.

Box #2 (this one, the primary, carefully built from parts, Intel iGPU, bought 1.6 years ago, new Samsung monitor bought about a month later, recently updated the monitor's firmware):

1. Desktop selection rectangle lags behind cursor.
2. Windows open with a serious perceived "flash", again *especially* when it is specifically the Wastebin being opened. As mentioned originally, all windows (whether Wastebin or not) are being partially drawn every single time, 100% unambiguously, and this also extends to any small "dialogue box" and other GUI elements as well. The "placeholder" icon in the top-left of the window also sometimes shows up for one frame before changing to the real icon, whether Wastebin or not.
3. Firefox ESR throws flashbangs constantly when closing tabs etc., as explained originally.

Box #3 (the Lenovo laptop, Radeon mobile GPU, bought only weeks ago):

1. Desktop selection rectangle lags behind cursor.
2. Same nonsense with the partially drawn windows. Furthermore, moving windows around with the mouse (whether external USB or the "nipple") is very noticeably lagging behind the cursor a lot.
3. Could not replicate the Firefox flashbangs here either, but it might again be temporary "luck".

Please note: There is some ambiguity due to me being forced to optically film the screens for box 1 and 3 instead of recording the screen in software. Even though the frames shows bleed-through visuals, I put those down to the old digicam blending the frames. I've been very "generous" to Xfce/Linux in these descriptions and only claim that it's partially rendered when that is completely obvious.

ToZ wrote:

Anything graphics related or errors would be of interest.

I carefully combed through the output but found nothing even vaguely related to graphics or errors except possibly (probably not) these two lines:

Jul 15 18:24:40 Towery kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks
[...]
Jul 15 18:24:44 Towery tumblerd[2193]: MESA: warning: Support for this platform is experimental with Xe KMD, bug reports may be ignored.

Have you tried with a different monitor and/or connector/cable?

Yes, in the past, but note that the two stationary computers use different monitors and cables, and of course the laptop has its own built-in screen.

ToZ · 2026-07-17 10:47:15

LinuxStruggler wrote:

`cat /proc/cmdline` now says: "BOOT_IMAGE=/vmlinuz-6.12.95+deb13-amd64 root=/dev/mapper/Towery--vg-root ro quiet i915.force_probe=!a780 xe.force_probe=a780"
`lspci -vnn | grep -A10 VGA` says:
Kernel driver in use: xe
Kernel modules: i915, xe
Yet the same damn issues remain, as if nothing had changed at all. Just like so many times before when I've tried similar things. It's surreal. I seriously start to get thoughts like my hardware is being intercepted when I order it home, modified in some way just to mess with me psychologically...

One further follow up - with the xe driver enabled, can you now try the different vblank modes for xfwm again. Note that the xpresent option requires the "libxpresent1" package installed. If it is not installed, install it and reboot first.

LinuxStruggler · 2026-07-19 02:28:29

ToZ wrote:

One further follow up - with the xe driver enabled, can you now try the different vblank modes for xfwm again. Note that the xpresent option requires the "libxpresent1" package installed. If it is not installed, install it and reboot first.

Booting in with the Xe stuff again (and verifying that it's active), I tried all:

xfconf-query -c xfwm4 -p /general/vblank_mode -s "off"
xfwm4 --replace &
xfconf-query -c xfwm4 -p /general/vblank_mode -s "glx"
xfwm4 --replace &
xfconf-query -c xfwm4 -p /general/vblank_mode -s "xpresent"
xfwm4 --replace &
xfconf-query -c xfwm4 -p /general/vblank_mode -s "auto"
xfwm4 --replace &

libxpresent1 was already installed. All of these modes have the same issues present, but they make the selection rectangle on the desktop even more laggy than before...

LinuxStruggler · 2026-07-25 15:08:55

I let the smartest AI that I have access to ("Qwen3.8-Max-Preview") analyze this thread. It took a long time to think, and then essentially responded with (paraphrasing from memory): "There is no possible configuration that will fix these issues. It is how Xfce works by design. You should wait for Wayland support or switch DEs to KDE."

From my experience trying out Wayland (not with Xfce, where it doesn't run at all), it's awful and breaks everything, so even if it would fix these issues, it would introduce many new ones. The Linux "ecosystem" seems perpetually stuck with X11, regardless of how good Wayland may be in itself in theory.

As for KDE/Plasma, it's staggeringly incompetently made to the point where I fled *back* to Xfce after wasting two years of my life trying to work around all its serious bugs. And the same sluggishness with selection rectangles was present there too, by the way. And while windows didn't *partially* open, they were slow to appear on there. I have no desire nor energy to switch DEs ever again unless something completely new and revolutionary is released which is as polished and responsive as Windows 95.

Just to make it crystal clear for anyone reading this: the problem is not solved whatsoever, and I'm completely out of any "leads" to even desperately try at this point.

daffyduck · 2026-07-25 19:05:19

Here is my 2 cents: I see you have tried all those changes, but perhaps it is simply a distro issue?

I would first systematically see which major component causes the issue, before guessing wild as you described so far.

To ascertain that the issue is specifically related to XFCE:
1. On the same Debian, try GNOME desktop
2. On the same Debian, try KDE desktop

To ascertain that the issue is not tied just to Debian, install other OS on an external USB drive:
Try Xfce on a new installation of EndeavorOS
Try Xfce on a new installation of Linux Mint (somewhat similar to Debian)
Try Xfce on a new installation of MX Linux (which is very similar to Debian)

Also: I have some MUCH older hardware running Xfce, in full software mode at 1920×1080, 60 Hz, completely fluid, no glitches, on two ancient cores. I typically disable the GPU-accelerated compositor, because it doesn't really make any difference, even on 10-year old laptops.
No glitches, no lag, no flashes ... perfectly stable.

Screen tearing ... Xfwm4 has a bit of barely noticeable screen tearing when running in non-compositing mode, but picom can do zero tearing without GPU acceleration.

So, you are experiencing something unusual. If it happens on multiple computers, it might be a bug in Debian.

Added later 25 min 36 s:
Regarding Xfwm4 (the default Window manager / compositor in XFCE).

It has two modes:
- compositing, where GPU acceleration is available
- non-compositing (direct-drawing), CPU-only mode.

In compositing mode, it should be theoretically impossible to observe any drawing "flashes", partial draws, blanks/whites, whatever.
The entire concept of a compositor is that it always, absolutely ALWAYS, composes only fully-drawn (completed) windows to the screen. That is usually accomplished by GPU-acceleration, but CPU can also do it (like with picom).
At worst, CPU compositing might not reach 60 Hz at 4K resolution, but only on very old cores.
Xfwm4 does not use compositing in CPU-only mode.
Only when compositing is disabled in Xfwm4, only then can you observe blanks/flashes.
On the picom compositor, all CPUs made in the last 5 years should be able to reach 60 Hz 4K using CPU only.

Added later 35 min 58 s:
============================
My final wild WILD guess:
For some reason, GPU driver fails to allocate buffers for double buffering, or mismanages them,
resulting in effectively a single framebuffer, which might explain some of the issues you described.
Or, perhaps some kind of deferred rendering is enabled for the GPU driver, where "drawing completed" function is malfunctioning for some unknown reason, therefore resulting in partial draws and laggy selection rectangle.

Last edited by daffyduck (2026-07-25 19:55:01)

vm_x · 2026-07-25 20:21:54

Whatever idea comes to mind, I disregard, because you're having these issues on three different computers.

I would start looking at something completely unrelated to Xfce, or even Linux, but common to all three computers. Maybe even something as wild as your electricity supply. Try taking that laptop to some other place away from your house, re-download and remake the USB stick there, and try reinstalling.

Sure, sounds weird, but this simply no longer sounds like a software issue, to the point I'm doubting you're a real person.

daffyduck · 2026-07-25 20:55:47

vm_x wrote:

I would start looking at something completely unrelated to Xfce, or even Linux, but common to all three computers.

But, both Xfce and Linux (and, Debian, too, but also MESA) are the same on all three computers he described. So, you are dismissing them prematurely.

Maybe even something as wild as your electricity supply. Try taking that laptop to some other place away from your house, re-download and remake the USB stick there, and try reinstalling.

Nah, that's never the case. Power supplies either work or don't. They may cause instability, but no power supply can cause partial drawing issues.

Sure, sounds weird, but this simply no longer sounds like a software issue, to the point I'm doubting you're a real person.

To me, it sounds very much like a software issue, particularly as OS issue. Perhaps Mesa, perhaps GPU driver, perhaps synchronization primitives. Some bug somewhere, that's exactly what it looks like.

============
Another note: the user seems to be using the brand new Intel "Iris" Mesa OpenGL driver, for a 14th Generation Intel Raptor Lake ("RPL-S").
Most compositors, including Xfwm4 in compositing mode, use OpenGL to composit windows to the screen.
MesaMatrix lists the "Iris" driver as one of the high quality OpenGL drivers.

Last edited by daffyduck (2026-07-25 22:39:05)

gogogadget · Yesterday 16:31:30

LinuxStruggler wrote:

From my experience trying out Wayland (not with Xfce, where it doesn't run at all), it's awful and breaks everything, so even if it would fix these issues, it would introduce many new ones. The Linux "ecosystem" seems perpetually stuck with X11, regardless of how good Wayland may be in itself in theory.

If KDE or Gnome don't work fine with Wayland, there's something wrong with your system, and no problem with Xfce, as long as you use a Wayland compositor. Tried a few weeks ago with Labwc, it didn't break anything.

startxfce4 --wayland

Last edited by gogogadget (Yesterday 16:35:12)

Xfce Forum

Sub domains

#1 2026-06-18 18:47:49

Inexplicably sluggish and glitchy rendering of basic desktop UI elemen

#2 2026-06-18 19:36:48

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

#3 2026-06-23 01:20:50

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

#4 2026-07-08 20:11:01

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

#5 2026-07-10 15:43:35

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

#6 2026-07-10 16:53:40

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

#7 2026-07-14 19:06:48

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

#8 2026-07-15 01:10:09

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

#9 2026-07-15 16:36:38

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

#10 2026-07-15 21:43:35

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

#11 2026-07-15 22:42:51

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

#12 2026-07-16 22:20:23

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

#13 2026-07-17 10:47:15

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

#14 2026-07-19 02:28:29

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

#15 2026-07-25 15:08:55

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

#16 2026-07-25 19:05:19

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

#17 2026-07-25 20:21:54

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

#18 2026-07-25 20:55:47

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

#19 Yesterday 16:31:30

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

Board footer