https://bugs.kde.org/show_bug.cgi?id=469279
--- Comment #3 from Kai Krakow <k...@kaishome.de> --- Thanks for investigating. I think this example shows that KDE/Plasma should treat VRAM as a valuable resource, and it affects a lot of other KDE background processes, too. So maybe creating some infrastructure to have one single process display dialogues for background processes may be the way forward. But I understand that this is a big change. As a less intrusive interims solution, Akonadi agent and resource processes could be forced to use Qt software rendering only. It probably won't hurt too much because most of these processes only open simple dialogues, and usually probably only in the event of errors or warnings, not as part of working normally. I found that forcing Qt software rendering for the full desktop to eliminate VRAM ballooning but, as already mentioned, I'm not sure how badly it will affect desktop performance, especially if desktops apps need to render in parallel to a game. Also, it somehow prevents window previews on the taskbar to work so it has a visible impact on user experience. But it may be acceptable for Akonadi dialogues for the time until this is fixed. I found no way to force software rendering only for processes launched by Akonadi, it should be as easy as injecting an environment variable into the launcher but I don't know how or where to do that. There's `/usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service` but I'm not sure if this is the right place for trying to inject environment variables, or if that is the launcher of the main process at all... -- You are receiving this mail because: You are watching all bug changes.
