Skip to content

Friday, 28 June 2024

(German version of this article: https://wordsmith.social/felixernst/mein-anteil-an-der-erstellung-des-hintergrundbildes-von-plasma-6-1-reef)

Plasma 5

A short recap: In Plasma 5 we predominantly had wallpapers with geometric features. They showed digital representations of nature or were completely abstract, which I never really liked. Perhaps that was trendy for a while, or maybe technical Linux users enjoy such wallpapers, which are quite obviously made using a computer. However, these days, we do not only offer the best package of security, privacy, usability, and power for tech enthusiasts, but for everyone. Therefore, it is in my opinion important that our wallpapers represent not just what we stand for but also what we want to enable. In the best case, we enthuse a broad public this way. We should move on from the purely technical towards what is human and incorporate the creative, inventive, or artistic, which will always be absent from machines. A down-to-earth example of this are wallpapers that look like they could be painted on a simple piece of paper.

Plasma 6.0

For the MegaRelease and Plasma 6.0 KDE arranged a competition for the next wallpaper. There was a jury, and even though I had no part in any of this, I was in full agreement with the jury about the winning image “Scarlet Tree”: As far as I know, the winning artist never made a public appearance and the only thing I know of them is their pseudonym “axo1otl”, under which the wallpaper was published. As far as I know, the communication with them was handled by Niccolò Venerandi.

Plasma 6.1

From then on, the release of Plasma 6.1 was inching closer. One could ask: Do we really need a new wallpaper for every new version?

Ask our Promo Team and they will say: Yes, of course!

The reason for this is that we want to show images of the new Plasma version, but not every new Plasma version includes changes to the default user interface. That would be quite annoying if we moved around buttons or changed the design two times a year!

But when we change the wallpaper, it becomes obvious: This is a new version. That wallpaper then moreso represents all the changes that happened below the surface.

Additionally. a new pretty image obviously also brings some colour and variety into the users' lives, if they haven't already switched their wallpaper themselves.

The plan was to keep the wallpaper for Plasma 6.1 in a similar style as the Plasma 6.0 one. The same artist “axo1otl” painted another picture for us. Unfortunately, we only got to see it somewhat late:

The Visual Design Group was not enthralled by it. The image is quite full, and therefore some of us thought that it was not suitable as a wallpaper. This reluctance was strong enough that people started discussing what we could use as a wallpaper instead, even though we did not have much time to make a decision.

I thought the image was good enough, but I was in a minority with that opinion. However, there was no quick way to find a popular replacement either. Some suggestions went back to our old geometric abstract style from Plasma 5 times.

Additionally, the picture was a bit too pretty to simply drop it. So there were attempts to edit the “Reef” wallpaper in a way that might fit our purpose.

Editings

Niccolò used blur: Oliver Beard from Wales moved some of the elements of the painting out of the frame, so the whole wallpaper would become more calm, like a backdrop: This was considered a step in the right direction.

Niccolò then combined both strategies: While watching these experiments, I noticed that the possibilities for adaptations were very restricted because nobody dared to personally add anything to the picture. That is why the reefs only grew in size in the images. Nobody made them smaller because it would mean creating empty space which would then need to be filled e.g. by adding new sand.

I already saw a future before us in which the time constraints would force us to publish such a hastily-constructed adaptation that hides or obscures many nice details of the original artwork. All that because we would not know how to help ourselves.

I did not want that to happen. I felt like I might and should perhaps be able to help here.

The thing is, I tend to work on the Dolphin file manager and regularly dive into the depths of its source code, so I know a thing or two about underwater landscapes. After all, I have been to two Dolphin meetings in the Mediterranean Sea in the last two years: At Barcelona and at Thessaloniki.

So I started editing the painting myself:

My plan was to make room so the image would seem more serene. Viewers should no longer feel like they are in the middle of a lively coral reef and more like they are wandering through the open sea. By moving the right reef to a new middleground and shrinking the castle, the depths and distances in the image grew. After some initial positive feedback, I added more and more of the missing elements.

Some contributors in the Visual Design Group did not like that the path at the bottom of the image did not lead to the castle anymore. To others, the path was generally an undesirable element which should be removed. I bent the visible end of it towards the castle:

The waves in the upper half of the images also needed to be completed. There were big holes where the two castle towers used to be.

The image above was the result of me working until 4 a.m. I only concluded once I considered the image good enough that I could honestly advocate for it to be a Plasma wallpaper. I hoped that my nightly work would ensure that we had a passable wallpaper ready in time for the Plasma 6.1 release.

When I awoke the next “morning,” I addressed feedback from the group. More people had voiced the opinion that they did not like the path. I had originally kept it because I tried my best to preserve as much of the original vision and technique of “axo1otl” as possible given my other changes.

Granted, the goal of this exercise was to make the wallpaper more calming. Removing elements goes hand in hand with that. It turned out that, for some, the path did not look like it was even leading to the castle. Others did not imagine themselves as wanderers on the path when they viewed the image.

So I removed it and also used that opportunity to improve the sand at the bottom edge of the screen so it would be closer in style to the sand I did not paint.

Finally, everyone was somewhat content with this. It might not be one of our best wallpapers of all time, but considering the time constraints it did not make a lot of sense to discuss this further.

However, we wanted to ensure that the original artist “axo1otl” was fine with the changes. The image would be published under their pseudonym after all.

The image was sent to them, and within one or two days they made a few final adjustments:

And what can I say? I like the changes. Better shadows and the drawing style of the water and sand I added were adjusted so one could no longer tell that they were painted by a different person. For this, some gradual colour transitions were replaced by discretely coloured steps.

So everything was fine and well, except the path reappeared. More generally, it seemed to me like the image was not based on my final version but on the one before that.

I might not know what happened there, but for me this was fine. Not everyone liked that the path reappeared, but considering that this is a rather minor detail, there was hardly any criticism.

Release

And then we released Plasma 6.1. However, due to unforeseen circumstances, the new wallpaper did not make it into the release! I will not elaborate on this topic, but I obviously was not happy to read that.

Furthermore, I noticed that the wallpaper that we nevertheless offered as a separate download was not the version “axo1otl” had sent us. It was my latest version. I hope “axo1otl” is not upset about that, but as far as I know, they will not create a new wallpaper for Plasma 6.2.

I have now created another version of the wallpaper based on “axo1otl”'s final version. The picture is identical to their version, aside from me removing the path. If you do not like the path, I would say that this is the best version for you. However, there are slight compression artefacts:

Plasma 6.2

For the next Plasma version our Promo Team wants a new wallpaper. There are already efforts to ensure that we will hopefully do a better job this time around.

I have suggested the creation of a new permanent category in KDE's forum in https://invent.kde.org/teams/vdg/issues/-/issues/52#note_972957 . I would want it to be a place for everyone to upload their self-made wallpapers. Maybe there are hobby artists out there who would enjoy doing that. I hope that some of the images would be great and well-suited as wallpapers for future Plasma versions to the benefit of us and everyone.

Let’s go for my web review for the week 2024-26.


Chat Control and the New Panopticon - by Masayuki Hatta

Tags: tech, surveillance, privacy, cryptography, law

Very neat piece, shows quite well the problems with Chat Control like laws. It’s been postponed this time, but expect it to comeback somehow.

https://mhatta.substack.com/p/chat-control-and-the-new-panopticon


Cleantech has an enshittification problem

Tags: tech, politics, law

This is becoming an important industry. Regulation is needed to avoid consumers to be in a mouse trap. This is necessary to reap the benefits of those technologies.

https://pluralistic.net/2024/06/26/unplanned-obsolescence/


Indirector

Tags: tech, cpu, security

A new type of attack targeting the CPU indirect branch predictor.

https://indirector.cpusec.org/


Polyfill supply chain attack hits 100K+ sites

Tags: tech, supply-chain, security, web

This is bad for two reasons: 1) people clearly put too much trust in random CDNs to distribute their dependencies and 2) people don’t track depencendies obsolescence properly.

https://sansec.io/research/polyfill-supply-chain-attack


The People’s AI – Doc Searls Weblog

Tags: tech, ai, machine-learning, gpt, foss, self-hosting

This is ignoring the energy consumption aspect. That said, it is spot on regarding the social and economics aspects of those transformer models. They have to be open and self hostable.

https://doc.searls.com/2024/05/28/the-peoples-ai/


On the Paradox of Learning to Reason from Data

Tags: tech, ai, machine-learning, gpt, research

Further clues that transformer models can’t learn logic from data.

https://arxiv.org/abs/2205.11502


Scalable MatMul-free Language Modeling

Tags: tech, ai, machine-learning, gpt, research

Interesting paper showing a promising path to reduce the memory and workload of transformer models. This is much more interesting than the race to the gigantic size.

https://arxiv.org/abs/2406.02528


Inside the tiny chip that powers Montreal subway tickets

Tags: tech, nfc, hardware

Nice reverse engineering of a NFC chip used in a disposable transportation ticket.

https://www.righto.com/2024/06/montreal-mifare-ultralight-nfc.html


Local, first, forever

Tags: tech, crdt, self-hosting, privacy

Interesting approach for using CRDT through a file sync application. Probably something to see somehow generalized on traditional desktop applications.

https://tonsky.me/blog/crdt-filesync/


Reladiff

Tags: tech, databases, tools, tests

Interesting tool for diffing database tables. Should come in handy for tests.

https://reladiff.readthedocs.io/en/latest/index.html


Performance tip: avoid unnecessary copies – Daniel Lemire’s blog

Tags: tech, performance

Interesting case, when everything else gets faster, memory copies might start to become the bottleneck.

https://lemire.me/blog/2024/06/22/performance-tip-avoid-unnecessary-copies/


How much memory does a call to ‘malloc’ allocates? – Daniel Lemire’s blog

Tags: tech, system, memory

If you needed to be reminded that allocating small blocks of memory is a bad idea… here is a paper explaining it.

https://lemire.me/blog/2024/06/27/how-much-memory-does-a-call-to-malloc-allocates/


How the STL uses explicit

Tags: tech, c++

Definitely not the rules you want to apply on your projects. Still it’s interesting to know how the STL uses explicit.

https://quuxplusone.github.io/blog/2024/06/25/most-stl-ctors-arent-explicit-but-yours-still-should-be/


Breaking out of nested loops with generators | mathspp

Tags: tech, python

This is a useful construct in Python which is often forgotten.

https://mathspp.com/blog/breaking-out-of-nested-loops-with-generators


The plan-execute pattern

Tags: tech, algorithm, pattern, design, architecture

A nice pattern to separate decision from actions in complex algorithms.

https://mmapped.blog/posts/29-plan-execute


Fighting Faults in Distributed Systems

Tags: tech, safety, distributed, failure

A nice zine introducing the topic of faults and failures in distributed systems.

https://decomposition.al/CSE138-2024-01/zines/zine-ali.pdf


From ZeroVer to SemVer: A Comprehensive List of Versioning Schemes in Open Source | Andrew Nesbitt

Tags: tech, project-management, version-control

A nice collection of versioning schemes. I definitely didn’t know them all.

https://nesbitt.io/2024/06/24/from-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.html


Of Psion and Symbian - by Bradford Morgan White

Tags: tech, history

Another story of precursors in the tech space. They basically invented the palmtop and spawned Symbian which was very much dominant on mobile for a while. The end of the Nokia story is a bit oversimplified for my taste just glancing over Maemo, but it is forgivable since it wasn’t the focus of this piece.

https://www.abortretry.fail/p/of-psion-and-symbian


Neko: History of a Software Pet

Tags: tech, history, funny

I remember playing with this a long time again… but it’s actually even older than I suspected.

https://eliotakira.com/neko/



Bye for now!

Wednesday, 26 June 2024

Kirigami Addons 1.3.0 is out. Kirigami Addons is a collection of components to enhance your Kirigami/QML application. This release contains many change related to the settings module.

ConfigurationView

The current way to create a settings page in your application is to use CategorizedSettings with some SettingAction for each setting page. This was based on Kirigami.PageRow which was then either pushed on a layer on mobile or to a seperate page on desktop. This turned out to be quite unreliable in practice as Kirigami.PageRow is a visual element.

The new ConfigurationView is based on a plain non-visual QtObject with for the moment two backends:

  • One for mobile which looks similar to the Plasma Settings application of Plasma Mobile.
  • One for desktop which looks similar to the System Settings application of Plasma Desktop.

The API is almost the same as the previous CategorizedSettings which made porting quite easy. Here is for example a button that open the settings.

import QtQuick.Controls as Controls
import org.kde.kirigamiaddons.settings as KirigamiSettings

Controls.Button {
 id: button

 KirigamiSettings.ConfigurationView {
 id: configuration

 window: button.Controls.ApplicationWindow.window as Kirigami.ApplicationWindow

 modules: [
 KirigamiSettings.ConfigurationModule {
 moduleId: "appearance"
 text: i18nc("@action:button", "Appearance")
 icon.name: "preferences-desktop-theme-global"
 page: () => Qt.createComponent("org.kde.tokodon", "AppearancePage")
 },
 ...
 KirigamiSettings.ConfigurationModule {
 moduleId: "about"
 text: i18nc("@action:button", "About Tokodon")
 icon.name: "help-about"
 page: () => Qt.createComponent("org.kde.kirigamiaddons.formcard", "AboutPage")
 category: i18nc("@title:group", "About")
 }
 ]
 }

 icon.name: 'settings-configure-symbolic'
 text: i18nc("@action:button", "Settings")

 onClicked: configuration.open()
}

With this change, both CategorizedSettings and SettingAction are now deprecated.

ConfigurationView on desktop
ConfigurationView on desktop

ConfigurationView on mobile
ConfigurationView on mobile

SpellcheckingConfigurationModule

With ConfigurationView each page is a ConfigurationModule and Kirigami Addons provides a ConfigurationModule for the spellchecking configuration of your application. This will allow to reduce code duplication between NeoChat, Tokodon, Marknote and more applications which uses Sonnet.

KirigamiSettings.ConfigurationView {
 modules: [
 KirigamiSettings.SpellcheckingConfigurationView {}
 ]
}

FormCard

FormCard design was slighly updated and now uses shadows as you might have already noticed from the previous screenshots.

SearchPopupField

Another component which is getting deprecated in SearchPopupField, there is now a replacement for that in Kirigami with the same behavior and I added an example how to port away to Kirigami.SearchDialog and I also ported all the know usage already.

Maintainance work

Aside from this major changes, there is ongoing maintaince works. This includes:

  • Removing the accidental QtWidgets on Android caused by QtLabs.ColorDialog (me: Carl Schwan)
  • Ensure all translated strings are loaded from the correct translation domain (me: Carl Schwan)
  • The license dialog in the AboutPage is now opened in the correct window (Jack Hill)
  • Fix the focus in the FormComboBoxDelegate (Joshua Goins)
  • Fix the capitalization in the AboutPage (Joshua Goins)
  • Increase the padding in FormCardDialog to match the other FormCard components

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

Tuesday, 25 June 2024

Hash-o-Matic 1.0.1 🔗

Carl Schwan CarlSchwan 10:10 +00:00
RSS

Hash-o-Matic 1.0.1 is out! Hash-o-Matic is a tool to compare and generate checksum for your files to verify the authenticity of them. It also verify files via their use PGP signatures.

This new release of Hash-o-Matic provides updated translations and some small visual changes. In the background, the application was ported to the new QML type registration, we now support building Hash-o-Matic on Haiku and we now require released version of KDE Frameworks instead of pre-released version.

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

KRdp in Plasma 6.1

It's been a while since I posted about KRdp. For those who missed it, KRdp
implements a server that exposes a running Plasma session to be controlled by
other machines through the RDP protocol.

The biggest news here is that KRdp is now part of Plasma and is being shipped
along with the rest of Plasma 6.1. Originally we hoped to be able to include it
for Plasma 6.0, but due to the amount of work getting everything else ready for
Plasma 6.0 we decided to postpone inclusion to Plasma 6.1. This allowed us to
include some fairly important changes that we wanted to include.

What's New

One of the most important changes to be included for Plasma 6.1 is that there is
now a KCM in System Settings to configure Remote Desktop support:

This removes the need for setting things up manually and should make it a lot
simpler to get started. This also adds support for logging in with multiple
users. This work was mainly done by Akseli Lahtinen, who has been taking over
more of the general development work for KRdp.

We also did a fair amount of work on the underlying libraries used for video
encoding to improve encoding speed and reduce latency. This should mean that
even with software encoding and a slow client, things should remain fairly
responsive, even though video quality might suffer somewhat.

Virtual Session Support

One thing that is being asked somewhat often is whether KRdp would allow a
remote user to login without a currently running session. Unfortunately,
currently that is not supported and there is no clear roadmap for when it will
be supported. Remote login requires quite some extra infrastructure to fully
work, not only in Plasma but other projects as well.

If you feel this is an important use case for you and you have the ability to
work on something like this, feel free to reach out to us to discuss things.
Ultimately having someone who is passionate about a use case working on it will
ensure things get developed a lot quicker. See the Get
Involved
page on the KDE Community wiki
on how to get started. For KRdp specific questions, feel free to ask them in
#plasma on Matrix.

Discuss this post on KDE Discuss

ahiemstra

Tellico 3.5.5 is available, with a few important fixes.

Improvements and Bug Fixes

  • Fixed the XSLT file loading to work correctly with libxml2 >= 2.13 (Bug 488707).
  • Fixed bug for showing entries with large content (Bug 487079).
  • Improved the SRU fetcher to allow user-defined search indices (Bug 488931).

Kommit 1.6.0 is a feature and bugfix release of our Git repo app which now builds with Q 5 or 6.

Improvements:

  • build without kdbusaddons on windows
  • Add flatpak support
  • Fix show date (using QLocale for it)
  • Fix mem leak
  • Reactivate open file in external apps in qt6
  • Add zoom support in Report Chart Widget
  • Replace a QTableWidget by QTreeWidget in report page
  • Fix crash when we didn't open git repository
  • Fix load style/icon on windows (KF >= 6.3)
  • Implement a gravatar cache
  • Fix i18n

URL: https://download.kde.org/stable/kommit
Source: kommit-1.6.0.tar.xz
SHA256: 4091126316ab0cd2d4a131facd3cd8fc8c659f348103b852db8b6d1fd4f164e2
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org
https://jriddell.org/esk-riddell.gpg

Monday, 24 June 2024

KWin had a very long standing bug report about bad performance of the Wayland session on older Intel integrated graphics. There have been many investigations into what’s causing this, with a lot of more specific performance issues being found and fixed, but none of them managed to fully fix the issue… until now.

The source of the problem

Understanding the issue requires some minimal understanding about how displays work. My earlier post about gaming on Wayland goes into more depth about them and the different presentation modes, but the TL;DR is that most displays today require frames to be sent to it in fixed intervals if you want them to be shown without tearing artifacts.

With the vast majority of displays, that interval is 16.67ms. In order to show everything as smooth as possible, the compositor thus has to render a new frame every 16.67ms as well; it must not miss a single deadline or the user will see stutter as some frames are shown twice and others are skipped.

This problem is not unique to Intel of course, when the deadline is missed, that causes the same stutter on every system. It’s just an often reported issue on old Intel processors because they’re used a lot, because both CPUs and GPUs in them are pretty slow, and laptop manufacturers too often paired them with high resolution screens, requiring the GPU to render for a long time each frame.

How KWin deals with this deadline

In the past, KWin would just start compositing immediately once the last frame was presented, to have as much time as possible for rendering; this worked pretty well but meant that it almost always rendered too early. On desktop GPUs, compositing can take as little as a few hundred microseconds; if we start compositing 16ms before the deadline, that means we’re also unnecessarily increasing latency by roughly 16ms, which makes the system feel less responsive.

For KWin 5.21, Vlad Zahorodnii implemented a scheduling mechanism to do this better: Instead of assuming we always need the whole frame for rendering, KWin measures how long rendering takes and could start compositing closer to the deadline, which reduced latency. However, this strategy could still not get very close to the deadline by default, because it only measured how long rendering took on the CPU, but not how long it took on the GPU.

For KWin 6.0, I implemented the missing part, recording GPU render times. This meant that we could reduce latency more, without causing stutter… Or at least that was the idea. It turns out, render times are very volatile at times; KWin’s rendering can be delayed by other apps using the CPU and GPU, by the hardware changing power management states, by additional windows opening, by KWin effects starting to render something heavy, by input events taking CPU time, and so on.

As a result, taking a simple average of recent render times wasn’t enough, and even taking the maximum wasn’t good enough to prevent all the noticeable stutter. Instead, KWin now analyzes past render times for how volatile they are, and starts compositing much earlier if they’re volatile, and only moves closer to the deadline when render times are stable and predictable. This will likely be tweaked a few more times as I can collect more render time data from different PCs and optimize that algorithm with it, but so far it works pretty well, and gets us the best of both worlds: High latency when necessary to prevent stutter, and low latency when possible.

So, with these old Intel processors, KWin should now detect that rendering takes long and render times are not very stable, and start rendering as early as possible, and that should fix everything, right? Unfortunately, that’s not the whole story.

Old Intel processors are just too damn slow!

On these old processors, especially when paired with a 4k screen, rendering doesn’t just take long, it often takes too long for a frame to be completed after 16.67ms! All the previous improvements were useful, but can’t make the hardware faster.

In the very beginning of the post I hinted that this is a Wayland only problem though, so what’s going on on Xorg? kwin_x11 has a trick that makes this problem less severe: On the start of each refresh cycle, it starts rendering a frame, even if the last frame isn’t done rendering yet. This is called “triple buffering”1 because it uses up to three buffers at the same time (two for rendering, one for displaying) and it has two big benefits:

  • while the GPU is still working on the last frame, the CPU can already prepare rendering commands for next one. As long as both CPU and GPU individually take less than 16.67ms, you can still get one image rendered for each frame the display can present
  • because more frames are being rendered, the driver may increase CPU and GPU clock speeds, which makes rendering faster and might allow for hitting the full refresh rate

However, it also has some caveats:

  • it increases latency in general, as rendering is started earlier than necessary
  • when rendering takes more than one refresh duration, latency is increased by a whole refresh duration - even if it would only need a single millisecond more for rendering
  • to avoid increasing latency for dedicated GPUs, it’s only active on Intel GPUs and never used elsewhere
  • it’s active even on Intel GPUs that have good enough performance to not need it
  • when the driver increases GPU clocks because of triple buffering, that may be enough for rendering to be fast enough to not need triple buffering anymore… which means the GPU clocks will reduce again, and frames will be dropped until triple buffering is active again, and that repeats in a cycle. This can, in some situations (like video playback), be more noticeable than a reduced but constant refresh rate.

The goal then was to implement a form of triple buffering that would come with the same benefits, without also having the same shortcomings. First, a few things needed to be patched up to allow for triple buffering to work.

Fixing prerequisites

The DRM/KMS kernel API currently only allows a single frame to be queued for presentation at a time. When you submit a frame to the kernel, you have to wait until it’s done rendering and shown on the screen, before you’re allowed to commit the next frame - but for triple buffering we need to queue two frames. Luckily I had already implemented a queue for other functionality with a drm commit thread (check out my previous post about cursor updates for details), so this one was mostly taken care of already and only needed minor changes.

The queue wasn’t good enough yet though. If KWin’s render time prediction is too pessimistic and it starts rendering much earlier than necessary, it could end up rendering two frames that are meant for consecutive refresh cycles, and complete rendering both during the same refresh cycle… which means that GPU power is wasted. Worse, as the refresh rate of apps is coupled to KWin’s, apps would try to render twice as fast too! To fix that, frames are now simply delayed until the time they’re intended to be displayed.

In order to figure out how long compositing takes on the GPU, KWin uses OpenGL query objects. These are quite useful, but they have three issues for triple buffering:

  • query objects only hold a single result. If you start two queries, the last one gets dropped
  • if you query a timestamp for commands that haven’t finished executing yet, OpenGL will do a blocking wait until that’s done
  • they’re bound to an OpenGL context, which especially complicates things with multiple GPUs

To avoid the last problem, I did a bunch of OpenGL refactors that removed unnecessary global state from OpenGL code, and encapsulated what was left in OpenGL context objects. Render time queries in KWin now store a reference to the OpenGL context object they were created with and handle the context switching for fetching the result themselves, so code using them doesn’t have to care a lot about OpenGL anymore. With that done, the other two issues were fixed by simply creating a new query for each frame, which gets queried after the frame is done rendering, and never gets reused.

Actually implementing triple buffering

After these prerequisites were taken care of, I extended the existing infrastructure for frame tracking, OutputFrame objects, to encapsulate more properties of presentation requests and handle render time tracking as well as presentation feedback directly. With all information and feedback for each frame being tracked in a single object, a lot of presentation logic was simplified and allowing multiple pending frames ended up being a relatively simple change in the drm backend.

To make use of that capability, I extended the render scheduling logic to allow render times of up to two frames. It computes a target presentation timestamp by calculating how many refresh cycles have gone by since the last presented frame and how many refresh cycles rendering will take. If there’s already a frame pending, it just ensures that the refresh cycle after that is targeted instead of the same one… and that’s almost it.

Remember how I wrote that displays refresh in a fixed time interval? Well, it’s not that simple after all. Timings can fluctuate quite a bit, and that could make KWin sometimes schedule two frames for the same refresh cycle, just for the older one to get dropped again and be a complete waste of energy and even cause stutter. As a fix, when the last frame completes and provides a more accurate timestamp about when the next refresh cycle begins, KWin now reschedules rendering to match it.

This is the state of things in the 6.1.0 release; since then issues on a few systems were reported and more adjustments may still be added - in particular, some sort of hysteresis to not make KWin switch between double- and triple buffering too often.

The result

With all those changes implemented in Plasma 6.1, triple buffering on Wayland

  • is only active if KWin predicts rendering to take longer than a refresh cycle
  • doesn’t add more latency than necessary even while triple buffering is active, at least as long as render time prediction is decent
  • works independently of what GPU you have

In practice, on my desktop PC with a dedicated GPU, triple buffering is effectively never active, and latency is the same as before. On my AMD laptop it’s usually off as well, only kicking in once in a while… But on some older Intel laptops with high resolution screens, it’s always active and I’ve been told it’s like having a brand new laptop - KWin goes from doing stuttery 30-40fps to a solid 60fps.

It’s not just old or slow processors that benefit though, I also tested this on a laptop with an integrated Intel and a dedicated NVidia GPU. With an external display connected to the NVidia GPU, due to some issues in the NVidia driver, multi gpu copies are quite slow, and without triple buffering, the external monitor was limited to 60fps. Triple buffering can’t do magic, but KWin now at least reaches around 100-120fps on that setup, which is likely the best that can be done until the driver issue is resolved and feels a lot smoother already.




  1. Keep in mind that “triple buffering” means a few different things to different people and in different contexts. I won’t go deeper into that mess here; just be aware that it’s a loaded term. 

The first month of the coding period of GSoC has already passed! Since the last update, I added Python support for the remaining classes of KWidgetsAddons. It was only recently when I discovered that apart from the C++ classes, the libraries also have namespaces which I didn’t even know about. So it turned out that it wasn’t actually completed. But anyway, there were only a few so that is now done. I also added support to automatically build a Python wheel for the bindings.

Last week I improved some Python demos and added bindings for KCoreAddons. That was quicker than I expected, so I might end up adding support for 5-7 more libraries that it was initially planned for. Here’s a list of the libraries that I plan to add during the rest of the summer:

  • KI18n
  • KGuiAddons
  • KNotifications
  • KUnitConversion
  • KXMLGui

Sunday, 23 June 2024

Cut through bullshit arguments fast and make project discussions more productive.