Updated: July 9, 2025
It is time to expand my testing some more. Now that I'm committed, it is time for fresh benchmarks. The story trail is somewhat long, so let me remind you. I tested Plasma 6.4, I got worried, I showed you various Wayland problems. To put my words where my mouth is or whatever, I decided to run a bunch of checks. First, I showed you Plasma idle desktop figures, two separate articles. Second, I did another experiment on an Nvidia hybrid graphics laptop, and added load tests - 4K video playback and some WebGL action.
Then, I went back to my AMD-powered, AMD-graphics laptop and redid the load tests in Plasma. All of my power, CPU, GPU, and FPS results show that X11 offers a superior, leaner performance, both in Plasma 5 and 6, both on AMD and Nvidia graphics. To make my testing complete, I am now going to redo everything in Fedora 42 Workstation Gnome. As Wayland as it gets. So let's see what gives. Beware, this is a very long, exhaustive article with tons of data. Do dedicate a nice chunk of time to read it.
Test conditions
This is what we're gonna do:
- A fully updated Fedora 42 Workstation Gnome edition.
- Idle desktop and loaded desktop benchmarks, similar to the KDE neon tests.
- Specifically, idle desktop vmstat, radeontop, powertop, and perf stat results.
- Specifically, vmstat, radeontop, powertop results while running a 4K 60FPS video in VLC with hardware acceleration.
- Specifically, WebGL Aquarium FPS results both with the charger plugged in and on battery battery.
- Comparison of all these measurements to Wayland Power Efficiency (PE) and Wayland Color Accuracy (CA) modes in Plasma 6.4 and X11 session in Plasma 6.4 on this same AMD-powered, AMD-graphics laptop, one IdeaPad 3 from 2019-2020.
- Now, I only chose X11 Composition ON results, to be more "fair" on Wayland. As we've seen in all my previous tests, including both AMD and hybrid Nvidia graphics, and for pretty much every single benchmark, running X11 without compositing yielded much better results overall.
Idle desktop results
All right, similar to what I did on this same AMD-processor, AMD-graphics laptop with KDE neon.
Vmstat data
The desktop be idling, with a single terminal window open:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Average no. of tasks in the runqueue | 0.23 | 0.18 | 0.35 | 0.07 |
| Total tasks in the runqueue | 13 | 11 | 21 | 4 |
| Interrupts (in) | 929 | 1188 | 1173 | 937 |
| Context switches (cs) | 536 | 1195 | 1208 | 803 |
| Idle CPU % (id) | 97.8 | 98.03 | 97.90 | 98.17 |
Okay, what do we have here?
- Wayland in Fedora 42 used 2.2% CPU on idle. This is higher than even Plasma's CA mode. Relative percentage wise, compared to the other three tests, Fedora generated 12%, 5% and 20% more cycles, the last being X11, of course.
- Wayland in Fedora did, however, generate the least amount of interrupts, and had the fewest context switches. The former is good, means less hardware work, the latter may not be good, potentially, as this could impact interactive latency. But it does depend on what's actually being done.
Now, the question is, does this behavior correlate to idle power figures?
Power data
Idle system, nothing running except a terminal window, battery drainage:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Battery drain (W) | 5.83-7.62 | 6.09 | 6.05-6.08 | 5.67-5.87 |
So, the answer is, yes and no, in a way. First, Fedora's power utilization fluctuated wildly, and I can't tell you what the most representative number should be. If we assume the best measured figures for all of the scenarios, it had better power consumption than Plasma Wayland by about 4%, and 3% worse than X11. If we look at the worst figures, the drainage was at least 25% higher. If we take the middle value of ~6.7 W, then Fedora's session consumed about 10% more battery.
Now, let's briefly look at my various distro tests over the years (on this box):
- Fedora 42 (Gnome) test gives an estimated 4 hours juice (normalized for battery wear).
- Fedora 41 (KDE) test gives an estimated 4-4.5 hours juice.
- Fedora 36 (Gnome) test gives an estimated 5-5.5 hours juice.
- MX Linux 23.4 (KDE) offered about 4-4.5 hours.
From here, we can see that distros are unnecessarily getting "fatter", for no good reason. Go back in time, even as little as 2-3 years, and you see much leaner systems, with better battery life. Has the desktop cardinally changed in all this time? Nope. Not at all.
Modern software feels a lot like electric cars - 500 kg more weight, 25% more price and you get 50% less range! What a bargain. But in all seriousness, there's no reason to go about using resources frivolously. There's art in making things compact, light, performant.
To answer my own question, is it possible that Plasma would offer 10% more juice due to lower idle system power consumption? Yes, looking at my more recent tests, yes. But an even bigger improvement can be had by making things leaner. Look at Fedora 36. Still Gnome. And still does better than the same Gnome roughly three years later, or even Plasma systems. Three years of ... desktop.
GPU data
I fired up Gnome's System Monitor. It ain't Plasma's, so the comparison isn't strictly 1:1, but those were my test conditions in KDE neon, so I need to sort of replicate them here. While the Monitor was up and running, in a separate terminal window, I ran radeontop.
First, a screenshot - look at all that noisy activity from a single program:
Lots of CPU work. Why? We shall explore later.
And now, the numbers:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Graphics pipe | 3.10 | 8.33 | 16.67 | 10.83 |
| Texture Addresser | 1.21 | 3.33 | 8.33 | 1.67 |
| Shader Export | 1.32 | 5.83 | 10.83 | 4.17 |
| Shader Interpolator | 1.83 | 5.83 | 11.67 | 5.83 |
| Scan Converter | 1.94 | 6.67 | 10.83 | 5.83 |
| Primitive Assembly | 0.08 | 0.83 | 0.83 | 0.83 |
| Depth Block | 1.72 | 5.83 | 10.83 | 5.83 |
| Color Block | 1.73 | 6.67 | 10.83 | 5.00 |
| VRAM | 12.03 | 49.19 | 50.33 | 38.99 |
| GTT | 1.19 | 6.24 | 6.50 | 6.31 |
| Memory Clock | 65.72 | 33.33 | 33.33 | 33.33 |
| Shader Clock | 16.67 | 16.67 | 16.67 | 16.67 |
On idle (with System Monitor running), Fedora Wayland used way fewer GPU cycles than anything I've measured in KDE neon, hands down. The only exception is the memory clock. From here, I have three interim conclusions as to why:
- The bulk of GPU work in Plasma comes from the badly optimized System Monitor, and/or Gnome's System Monitor does not utilize the GPU, which seems to be the case from its very own screenshot.
- Wayland GPU work in Fedora is much better than Plasma's implementation, however, this does not seem to agree with all the other data I've gathered and analyzed so far.
Whether this makes sense, we will also look at the loaded figures soon, to see what gives.
Kernel (perf) data
Once again, as we did in KDE neon. An idle desktop, 60 seconds worth of samples:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| CPU clock (ms) | ~492,000 | ~543,000 | ~540,000 | ~527,000 |
| Context switches | 9,468 | 19.244/s | 14,415 | 26.547/s | 16,120 | 29.864/s | 6,021 | 11.436/s |
| CPU migrations | 104 | 0.211/s | 72 | 0.133/s | 139 | 0.258/s | 92 | 0.175/s |
| Page faults | 2,010 | 4.09/s | 201 | 0.37/s | 450 | 0.834/s | 75 | 0.142/s |
| Cycles | 30B | 0.061 GHz | 3.95B | 0.007 GHz | 4.43B | 0.008 GHz | 1.9B | 0.004 GHz |
| Stalled cycles frontend | 1.96B | 6.54% | 452.5M | 11.47% | 616.5M | 13.92% | 213M | 11.13% |
| Stalled cycles backend | 3.5B | 11.66% | 1.42B | 36.04% | 1.45B | 32.82% | 618M | 32.28% |
| Instructions | 13.5B | 0.45/cycle
0.26 stalled/cycle |
780M | 0.2/cycle
1.82 stalled/cycle |
901M | 0.2/cycle
1.61 stalled/cycle |
483M | 0.25/cycle
1.28 stalled/cycle |
| Branches | 3.18B | 6.46M/s | 168M | 309K/s | 193M | 358K/s | 104M | 197K/s |
| Branch misses | 5.48% | 13.83% | 13.36% | 11.7% |
Oh, some hot data!
- Fedora used the least amount of CPU clock time, which is good.
- It had an order of magnitude more page faults, but this makes sense as it also had more than 10x instructions, and roughly 10x more cycles.
- It did better on getting things through the execution pipe, with fewer stalled cycles and branch misses.
- It required a higher CPU clock to get everything done, roughly 7-15x more.
In my (educated) view, this probably has more to do with the kernel itself than Wayland, considering the differences among Wayland sessions, X11 notwithstanding. So, from what we've seen so far, Fedora's Gnome Wayland implementation seems worse than Plasma's, but Fedora's kernel seems better optimized than the one used in KDE neon (essentially Ubuntu).
From here, my interim conclusion is that Fedora Gnome Wayland does more work on idle, which is reflected in the idle CPU and power figures. But, to see the other end of the spectrum, we also need the high-load scenarios.
4K 60FPS video playback results
Here, like in my Nvidia scenario, I also had problems with getting the clip running. I had to install all sorts of codecs for Fedora to even deign playing the video in VLC (or any other player, for that matter). We shall expand on this later on, but now, let's focus on the numbers.
Vmstat data
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Average no. of tasks in the runqueue | 2.83 | 2.4 | 2.37 | 0.8 |
| Total tasks in the runqueue | 99 | 84 | 83 | 28 |
| Interrupts (in) | 7845 | 7772 | 7033 | 6703 |
| Context switches (cs) | 5986 | 6561 | 6357 | 7117 |
| Idle CPU % (id) | 70.4 | 68.49 | 74.29 | 90.20 |
From here, we can see the following:
- Wayland in Fedora 42 Gnome did a little better than Wayland (PE) but not Wayland (CA) in Plasma 6.4. It utilized 29.6% CPU compared to Plasma's 31.51% and 25.71%, respectively, which is still a lot more than X11's 9.8% utilization. So, effectively 3x more cycles than X11. On the Wayland side, Fedora did 6% better than KDE neon PE mode, but 15% worse than the CA mode. I don't have a good explanation why CA would return better results. But we've seen this reversal a few times.
- Wayland in Fedora executed the highest number of interrupts (aligns with the session responsiveness), and had the fewest context switches (aligns with interactive responsiveness, as the execution seemed more geared toward computation rather than latency).
GPU data
Let's look at the radeontop numbers!
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Graphics pipe | 58.21 | 56.33 | 57.33 | 57.98 |
| Event Engine | 0.00 | 0.00 | 0.00 | 0.00 |
| Vertex Grouper + Tesselator | 0.59 | 0.64 | 0.36 | 0.5 |
| Texture Addresser | 52.52 | 50.50 | 51.83 | 39.55 |
| Shader Export | 51.59 | 49.43 | 51.21 | 28.88 |
| Sequencer Instruction Cache | 0.14 | 0.09 | 0.12 | 0.12 |
| Shader Interpolator | 53.96 | 51.74 | 52.83 | 52.76 |
| Scan Converter | 53.36 | 50.83 | 52.60 | 29.05 |
| Primitive Assembly | 0.55 | 0.48 | 0.40 | 0.38 |
| Depth Block | 53.14 | 50.69 | 52.29 | 28.86 |
| Color Block | 52.93 | 50.69 | 52.50 | 28.93 |
| VRAM | 50.89 | 23.29 | 24.60 | 44.36 |
| GTT | 19.02 | 17.58 | 17.67 | 4.34 |
| Memory Clock | 79.24 | 76.39 | 76.05 | 76.46 |
| Shader Clock | 24.01 | 18.37 | 18.79 | 21.75 |
Fedora's Wayland results, and some additional, startling mid-conclusions:
- Worst results across the board on the GPU side, with only the Vertex Grouper + Tesselator value slightly lower than Wayland (PE) in KDE neon. This is the opposite of the results we got with System Monitor running.
- Fedora Wayland used more resources, including the graphics pipe (1.5%) than the "worst case" KDE neon Wayland scenario, and more than twice the VRAM than either one Wayland result in Plasma, and 15% more than the X11 session. The same applies to GTT. Likewise, the memory and shader clocks frequencies were the highest of all four options, 4% and 28% higher, respectively, than the "worst case" KDE neon Wayland data.
So, if we look at idle desktop (plus System Monitor) GPU data once again:
- The 4K playback results do not agree with those numbers.
- In fact, looking across the board, Fedora's Wayland seems less performant across multiple data vectors, i.e., idle desktop (System Monitor) GPU data do not agree with any other test I've done so far.
- From here, it would seem that the source of significant workload on the GPU size in Plasma comes from Plasma's System Monitor itself. Considering my experience with this program over the years plus the perf data from the KDE neon test, it seems quite likely.
- Similarly, Gnome's System Monitor seems to be CPU-bound, which would explain the screenshot earlier. This may also point to a different type of problem in the software implementation, but that's a separate topic.
BTW, during the playback, Wayland in Fedora never triggered fewer than 10% GPU pipeline. The lowest number was 10.00%. From the saved radeontop dump file:
...
1751902542.525747: bus 3
gpu 35.00% ee 0.00%
1751902543.525983: bus 3
gpu 10.00% ee 0.00%
1751902543.548317: bus 3
gpu 10.00% ee 0.00%
...
From here, we can see that Plasma's Wayland implementation seems to offer better results when playing a video, speaking of Wayland results only, that is. This does align with what I've been saying for years and years and years. Now, you got some numbers to crunch, too.
Power data
While playing the video, I recorded the following battery figures:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Battery drain (W) | 12.5-15.6 | 13.8-20.4 | 13.8-14.1 | 11.4-14.9 |
Best case scenario, Fedora used less juice while rendering the video (Wayland), but worse than X11. About 10% less than either PE or CA, but 10% worse than the old X11. Worst case scenario, the utilization was about 10% worse than CA and about 5% worse than X11. The PE power spike might be an anomaly, but I'll let you interpret the data however you like it.
- The possible 10% difference does align with the idle power figures and estimated battery life.
- The possible 10% difference does agree with CPU data and loaded GPU data.
Now, let's look at the WebGL stuff.
WebGL Aquarium simulation
Much as I did in the previous tests, I launched the page in Firefox, and rendered 15K, 20K and 25K fishes, oh fishy fishy fish, and then measured FPS results, once with the charger plugged in and once on battery power. First, let's look at the charger plugged in values:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Fish count: 15,000 | 26-29 | 16-38 | 18-37 | 16-42 |
| Fish count: 20,000 | 18-22 | 18-30 | 13-30 | 15-23 |
| Fish count: 25,000 | 17-18 | 12-23 | 10-23 | 14-27 |
And on battery power:
| Metric | Fedora 42 Wayland | KDE neon Wayland (PE) | KDE neon Wayland (CA) | KDE neon X11 (Comp ON) |
| Fish count: 15,000 | 17-19 | 17-29 | 16-27 | 21-29 |
| Fish count: 20,000 | 14-15 | 13-22 | 12-21 | 18-30 |
| Fish count: 25,000 | 11-12 | 10-18 | 10-18 | 13-19 |
- If we look at the higher FPS recorded, no matter which way you look at it, Fedora's Wayland generated fewer frames, 8 fewer for the 15K/20K scenario and 5 fewer in the 25K scenario, when charged. With the battery usage, the delta was 6-10 frames. Wayland to Wayland. And if you recall the KDE neon test, Wayland had about 4 FPS worse results than X11 while plugged in, 1-2 FPS when running on battery juice.
- Unlike the Plasma session, there were almost no fluctuations in the FPS count.
These are significant numbers, and differences, because in many of the cases, Plasma Wayland was able to do 30-50% more frames than Gnome Wayland, and X11 was better still by 10% than Wayland in KDE neon. This is lots of frames.
Again, these results agree with everything we've seen so far. This could be due to how Firefox works in Fedora, Gnome, Wayland, or all three. However, given Wayland results in Plasma, it may be possible that Firefox works differently on this other distro and desktop environment, and that there are problems under the hood. A separate problem. But the numbers are what they are.
An side, getting VLC to play MP4 in Fedora
This was a big pain, and it demonstrates how nerdy the Linux desktop is. So, I tried to launch the test file, the same one I used in KDE neon and Kubuntu 24.04, and I got this error:
[libopenh264 @ 0x7f4c8cc7dd40] DecodeFrame failed
So, I needed codecs. Nothing in the existing enabled repos helped, even though I did specify the use of third-party sources in the first-run setup. I had to manually configure RPM Fusion Free and Nonfree for all, and install a bunch of stuff. But I also had to fight various package conflicts:
...
- package ffmpeg-7.1.1-6.fc42.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free
provided by ffmpeg-free-7.1.1-4.fc42.x86_64 from updates
- package ffmpeg-7.1.1-6.fc42.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free
provided by ffmpeg-free-7.1.1-3.fc42.x86_64 from fedora
...
So I "brute-force" installed a bunch of plugins and codecs:
sudo dnf install --allowerasing gstreamer1-plugins-base gstreamer1-plugins-good gstreamer1-plugins-ugly gstreamer1-plugins-bad-free gstreamer1-plugins-bad-freeworld gstreamer1-plugins-bad-free-extras ffmpeg
The year is 2025. One should NEVER have to do this. Gstreamer, good, bad, ugly. Nonsense. This is a problem a million times worse than Wayland vs X11. A horrible, horrible end-user experience.
Then, I checked VLC was using hardware acceleration:
avcodec decoder: Using Mesa Gallium driver 25.1.4 for AMD Radeon Vega 8 Graphics (radeonsi, raven, ACO, DRM 3.63, 6.15.4-200.fc42.x86_64) for hardware decoding
But it still spat out VDPAU errors!
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
What nonsense. 2025, and we play the Windows XP codecs game. You get similar problems in other distros. And these are the critical user-facing issues. The fact no one has created a meta package called MEDIA CODECS as I've written probably a decade ago. No, let's have things like gstreamer, because that totally makes sense. Not MP3, not MP4,not music or video, nope. Sure, freeworld and free-extras, so much logic! Such experience, much wow, great user story!
An important aside, major security risks
All of this highlights all the paradoxes of the Linux desktop:
- Wayland folks talk about X11 "keylogger" vulnerability, but to be able to play a video, a simple file from the Blender Foundation, I had to add third-party sources to my desktop.
- Then, I effectively broke package management by force-installing a bunch of stuff.
- I effectively broke the security mechanisms of my distro as I in fact circumvented them.
- Paradoxically, sadly, Fedora comes with Flathub enabled by default, and you can install software from there, including unverified packages. You have the Chrome and Steam repos enabled, too, but you also can install unverified Chrome and Steam Flatpaks from above! More potential source conflicts like my RPM Fusion scenario. And in my mind, the security risks of these actions are 100x worse than any imagined X11 vulnerability.
Look at these screenshots please. Fedora's software sources, Flathub enabled and there's a Google Chrome repo.
If you search in Software for Chrome, you get a Flathub results. Not the official Chrome from Google! Even though Fedora actually gives you the original Google repo. See above.
If you check Flathub, it says Unverified! In Software, the only way to notice this ain't the actual Google thing is the tiny note on the wrapper. And take into account that Chrome is probably the most prominent piece of software on this planet.
This is astounding. Why would anyone offer the end user a BROWSER that is not officially packaged? Keylogger in X11? How about an UNVERIFIED browser that can potentially do anything and everything with user's data, including logins to sites and such.
Unverified does not mean bad. But it also does not mean good. Could be ... anything. Toss a coin. And all the while, the official, verified Google's own Chrome is NOT offered in the search!
Does anyone even care about the implications of this?
What happens if some normie gets pwned or hax0red by using an unverified browser? Who is responsible? The upstream source for allowing an unverified package to be hosted? Gnome Software for showing this thing to the user (and also not the original program)? Fedora for enabling this?I know that if I were to run a distro or a community store, I would not dare offer something like this. I simply wouldn't dare.
I may need to write a separate article about this, because obviously, having written about this in openSUSE Tumbleweed, Fedora Kinoite and Zorin OS reviews isn't enough. This is a huge potential security risk. Right there. Not some pseudo-risk of a rogue application "sniffing" you X11 session. Nope. This. Offering unverified third-party content through the distro's package manager - side by side with the official content not being offered.
Again, this ain't some tiny random program no one wants to package for Linux. This is Chrome. The most popular browser in the world. And In my Zorin OS review, I showed you a rather similar problem with Steam, the biggest gaming platform in the world.
To make this an even bigger tragedy, Fedora actually offers you the OFFICIAL repositories for these two packages, out of the box. And yet, Software still manages to bungle it and send the user to random, community-packaged versions of these programs. Are they safe? Who knows? Maybe.
Windows, totallysafe.exe.
This is the equivalent.
2025, Linux has managed to created the Windows user experience. The 2001 version, let's hunt for software around the Web, maybe we can find something cool and it won't install an ActiveX in my brain. Awesome!
My most sincere suggestion to all of the distro folks out there, please make sure, whether it's Flatpaks or snaps or whatever, you don't show any unverified packages by default. You give the user a button to click and choose whether they want to see non-official contributions and packages. And you show a giant red warning, twice, about the potential implications of what happens if they do allow them.
Conclusion
That was long, and to be fair, quite exhausting. The results are quite interesting. By and large, Gnome Wayland, as implemented in Fedora, seems slightly less performant than Plasma's Wayland, which in turn, is less performant than X11, and as we've seen that, too, is still worse than X11 with compositing off. Significant numbers that, to me, tell one things: it's too early to deprecate the old framework, because the new one still hasn't caught up. No emotion, no fanboyism, simple pragmatic c'est la vie.
If we look just at Wayland, on idle, Gnome performed worse in battery use and CPU data, with surprisingly good GPU numbers that do not align with any other test. Under load, again, Gnome's Wayland used most resources, and had the worst FPS count by far. Furthermore, Fedora's kernel seems to be doing a lot more work, but also doing it quite efficiently. Lastly, both Plasma's System Monitor and Gnome's System Monitor seem to be badly optimized tools, given what we've seen so far.
To sum it up, X11 is still the most optimal choice, performance wise, to say nothing of the compositing off option, which blows the rest out of the water. Plasma's Wayland implementation is better than Gnome's, it seems. Both still lack a lot. This highlights the tragedy of the forced X11 deprecation. To top it all off, you get unverified packages and a codec vomit mess, to remind you how far Linux still has to go before it can be a normal solution for the normies. Hint: don't copy the worst parts of Windows. There. Solved. Bye.
Cheers.