Updated: July 15, 2020
While we're busy a-tutorialin' on all manner of topics regarding Raspberry Pi 4 that I got a few weeks back, I decided to expand my initial set of work beyond (mostly) the MATE desktop and see how well other desktop environments handle the heat. Literally and figuratively. Hi hi. Anyway, we have the results from Raspberry Pi OS and Ubuntu MATE, with some notable differences, but overall, you get a fairly consistent and fast experience. Then, I also got me testing the ARM spin of Manjaro KDE, which provided to be neat if under-optimized.
Early on in my Raspberry Pi 4 games, I did load the official operating system with both Xfce and Plasma, just to see what gives. I told you that Plasma was sluggish, and kind of left it there. But encouraged by the Manjaro test, I revisited this effort. After all, Plasma is super nice, so if it runs well, well ... Let's see what gives.
Discrepancies, customization, taming the system
I am amazed and dismayed, every single time, how much variance there is among distributions, and even among seemingly identical desktops. For example, Manjaro offers KDE 20.04. Raspberry Pi OS has Plasma 5.14 in its (Debian) repositories. This is an old build, and I'm not sure how well supported and maintained it is, given that KDE has two LTS - Plasma 5.12 and the more recent Plasma 5.18.
So I sat down and did my mandatory Plasma setup: changed the font color to black and thus created a custom theme called Brooze; did some basic polish and tweak, sorting out the appearance; added a minimize all windows widgets and transformed the task manager to icons only. After a few minutes, the desktop looked the part.
Performance
But one thing my early work could not fix was the abysmal performance. And I mean abysmal. The desktop was super slow. Everything would take a long time happening, including basic things like launching Dolphin. I wanted to see if this was caused by compositing - alas, the option to manage compositing is not available. The ARM version of Plasma is built differently from the x86 edition(s), and some of the tools and utilities are simply not there. This is also true with other desktops, like MATE and Xfce, but two wrongs don't make a right.
I had to resort to using the command-line qdbus commands to get compositing off:
qdbus org.kde.KWin /Compositor suspend
BTW, to turn it on, you can run:
qdbus org.kde.KWin /Compositor resume
As soon as I suspended compositing, the performance got sooooooooooooo much better. The desktop actually became usable. Reasonable performance. Occasional stutter now and then, and some small if perceptible delay getting things running and whatnot, but a vast, monumental improvement over the default configuration.
Now, if we compare to MATE - MATE is still sprightlier. Quite a bit. The Plasma build is simply not optimized at all for this particular architecture. To put things into perspective, working with MATE off an SD card that has an average read rate of about 40 MB/s (like a 5,400rpm disk more or less), the general speed is roughly equivalent to about 60-70% of what I get on my multi-boot 2015 Lenovo G50 (say with MATE or Plasma), excluding the graphics processing capabilities. With Plasma, the responsiveness is about 20-30%, and perhaps equivalent or even slightly worse than my 2009 Asus eeePC netbook running MX Linux - again, excluding the video side of things. These are not accurate numbers, and there's much more to it - like sustained I/O operations, sustained CPU workloads, and the choice of the desktop environment also plays a huge part. But this gives you a rough indication of what the software currently does.
Video performance
This aspect isn't affected by the choice of the desktop - so the results are like what we saw in LXDE or MATE, and you get a reasonable 25-ish FPS with the WebGL Aquarium 1024x1024 frame 500-fish simulation, plus smooth HD playback in all the browsers plus VLC - after the necessary 3D tweaks, of course, as you will need to make sure the software is configured to use hardware acceleration.
Heating
Because the desktop environment isn't optimized, CPU utilization is massive, and consequently, the Pi got really hot. The hottest I noticed so far. The Flirc case was almost too hot to touch. This does not align with my idea of a small desktop purring happily and doing its desktopy stuff.
Other things
In the end, I had a working desktop. There were problems, of course. For instance, Dolphin seems to complain about conflicting shortcuts. Plasma crashed the first time I tried to change the wallpaper. Unlike the Manjaro experience, LibreOffice did not refuse being pinned and moved about in the task manager. Some applications don't render correctly, with only partial theme elements and decorations. I'm not sure why, but again, it's possible the Plasma build is simply broken and unusable.
Most windows have unnecessary alpha borders - but this one does not.
And neither does this one ...
Spectacle buttons are not showing properly.
Notice the white title background; why is hardware reported as ARMv7, isn't it meant to be ARMv8?
Conclusion
After I completed my testing, I powered down the Pi, let it cool, and then turned it on again and continued using the MATE desktop. While I'd love to have a tight, nifty Plasma setup in place, the existing packages in the Raspberry Pi OS repos are simply not built for purpose. You get an old build, which suffers from all sorts of bugs and problems and woeful performance. Add to that Samba issues - not resolved in this Plasma version - and MATE just offers a superior experience on all levels.
In a way, this has always been the paradox of open-source choice. On paper, you get tons of options, but when only one or two actually work properly, then your bubble of freedom narrows down quite a bit. For instance, here, I'd like to use Plasma on the Pi, but neither of the last two experiments offered me a setup that is good enough, for whatever reason. Specifically, the Plasma desktop available in Raspberry Pi OS just doesn't do any justice to itself, or the system. But in a way, this is what I tried to accomplish. Another aspect of the question of using Pi 4 as a mini desktop has been answered. We're done.
Cheers.