When switching rendering backend and hitting apply, it seems that the rendering backend is switched. For me the actual switchung took about 30 seconds, but there is no visual feedback that the switiching is in progress or that the switching is done. Reproducible: Always Steps to Reproduce: 1. Switch rendering backend 2. Hit apply Actual Results: No visual feedback Expected Results: Some feedback, or at least some hint/notification that the user has to wait a while until the process is finished.
can you please explain why you need visual feedback there?
> switching took about 30 seconds KDE still runs on a 486 SX? :-P A "background job" should probably tell you that it finished (and the return code), but switching the backend takes ~250 MILIseconds here (if at all) and the combobox would revert on failure. Can you please verify that something (and the correct thing) happened? qdbus org.kde.KWin /KWin supportInformation | grep Compositing
my screen flickered very heavily. I was using Xrender for compositing and switching to OpenGL didn't seem to help at all. After hitting apply the screen flickered even more. Only after about 30 seconds the flickering stopped. But the first few times I didn't wait so long an decided to go back to Xrender useCompositing: true Compositing Compositing is active Compositing Type: OpenGL
seems the render extension is broken w/ your driver/HW -> can you please attach /var/log/Xorg.0.log?
Created attachment 92849 [details] Xorg.0.log
Thanks [ 601.096] (--) RADEON(0): Chipset: "ATI Radeon HD 5450" (ChipID = 0x68f9) [ 601.096] (II) LoadModule: "exa" [ 601.096] ABI class: X.Org Video Driver, version 19.0 [ 601.096] (II) RADEON(0): KMS Color Tiling: enabled [ 601.096] (II) RADEON(0): KMS Color Tiling 2D: enabled [ 601.096] (II) RADEON(0): KMS Pageflipping: enabled ... [ 601.336] (II) RADEON(0): mem size init: gart size :3fdde000 vram size: s:20000000 visible:18ee6000 [ 601.336] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM ----- If you encounter further/different issues (flicker inside applications etc.) or you want to use xrender, you may try whether one of the following options (deactivate everything, then re-activate them one-by-one and check whether one causes failure) helps. Section "Device" Identifier "Radeon" Driver "radeon" Option "EXAVSync" "off" Option "ColorTiling" "off" Option "EXAPixmaps" "off" Option "RenderAccel" "off" EndSection
I disabled all of them and it got better. Still some flickering, but less then before and mostly when hovering over the taskbar entries. Disabling the taskbar tooltips improved it even further. OpenGL rendering only worked once really good. If I switch now it starts to flicker very heavily. I'll attach current Xorg.0.log and the output of "qdbus org.kde.KWin /KWin supportInformation"
Created attachment 93102 [details] Xorg.0.log
Created attachment 93103 [details] Output of qdbus org.kde.KWin /KWin supportInformation
There's definitivels some issue with cedar chips. https://forum.kde.org/viewtopic.php?f=289&t=126762 has a report on GL compositing, no idea whether XRender is affected for him as well. By that I'm not sure whether GL ever really worked for you - or changing actually took 30 seconds. The flickering will have stopped for other reasons and as GL & XRender are affected, the flicker is probably not (directly) caused by KWin but somewhere in the driver (but given your last report on deactivated features, I'm out of idea "where") It seems to be related to redirection (ie. compositing)? Does (w/ the compositor suspended "SHIFT+Alt+F12") eg. glxgears flicker? Another potential cause might be the QML contexts. start konsole (or xterm) and kwrite, close all other windows. then from konsole "kquitapp plasmashell" (your desktop just disappeared, don't fear ;-) => does compositing (xrender or opengl) still flicker?
I turned off compositing: qdbus org.kde.KWin /KWin supportInformation | grep Compositing useCompositing: true Compositing Compositing is not active glxgears is running without flickers, but if I switch window focus it still flickers. When moving the mouse over the taskbar entries mouse movement gets really slow. After quitting plamsashell it still flickers with OpenGL. I didn't see any flicker with XRender, but as I have flickers with XRender mostly when moving over items in the task bar and switching focus between windows, its hard to tell.
You say you get flicker -with compositing suspended!- when changing the active window?
Yes, I just tested it again. useCompositing: true Compositing Compositing is not active and it flickers when switching windows.
Ok, good news for us is that this is then not a kwin bug for sure. Bad news for you is that there's a severe issue with the graphics driver. From the triggers (plasma tooltips, window switching - you use a tabbox, ie. a box with window icons when switching?) I'd say it's somehow related to creation of a QtQuick graphicsscene (ie. OpenGL) Does this have any impact? kquitapp plasmashell LIBGL_ALWAYS_SOFTWARE=1 plasmashell & LIBGL_ALWAYS_SOFTWARE=1 kwin_x11 --replace &
When switching windows, I was only talking about switching focus, not actually using ALT TAB, but just click with the mouse. Yes it seems like the flickering is gone now. I enabled tooltips in the taskbar and no flickers there so far either. I can not switch to OpenGL Compositior any more , but I guess that's what LIBGL_ALWAYS_SOFTWARE=1 enforces?
(In reply to Fabian from comment #15) > Yes it seems like the flickering is gone now. I enabled tooltips in the > taskbar and no flickers there so far either. Neither when activating windows? > I can not switch to OpenGL Compositior any more , but I guess that's what > LIBGL_ALWAYS_SOFTWARE=1 enforces? It enforces to use the software rasterizer - and we protect you from running a system at 10 fps ;-) (You can enforce opengl compositing, but you don't want to)
After using it some more. No flickering is not gone completely. It seems it start again as soon as the system is under a higher load. (or if I open chromium).
I think there should not be any visual feedback when the compositing backend got changed. The strength here is that the user should not see that this changed, it should work smooth. If it doesn't we have a bug. For everybody having this working a message would be wrong.