Bug 348302 - Missing visual feedback when switching rendering backend
Summary: Missing visual feedback when switching rendering backend
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 5.3.0
Platform: OpenSUSE Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-27 11:58 UTC by Fabian
Modified: 2016-08-29 08:25 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Xorg.0.log (710.97 KB, text/x-log)
2015-05-27 12:36 UTC, Fabian
Details
Xorg.0.log (812.03 KB, text/x-log)
2015-06-10 08:07 UTC, Fabian
Details
Output of qdbus org.kde.KWin /KWin supportInformation (4.83 KB, text/plain)
2015-06-10 08:08 UTC, Fabian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian 2015-05-27 11:58:41 UTC
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.
Comment 1 Martin Flöser 2015-05-27 12:02:35 UTC
can you please explain why you need visual feedback there?
Comment 2 Thomas Lübking 2015-05-27 12:06:56 UTC
> 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
Comment 3 Fabian 2015-05-27 12:19:32 UTC
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
Comment 4 Thomas Lübking 2015-05-27 12:33:24 UTC
seems the render extension is broken w/ your driver/HW
-> can you please attach /var/log/Xorg.0.log?
Comment 5 Fabian 2015-05-27 12:36:14 UTC
Created attachment 92849 [details]
Xorg.0.log
Comment 6 Thomas Lübking 2015-05-27 21:58:12 UTC
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
Comment 7 Fabian 2015-06-10 08:06:17 UTC
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"
Comment 8 Fabian 2015-06-10 08:07:07 UTC
Created attachment 93102 [details]
Xorg.0.log
Comment 9 Fabian 2015-06-10 08:08:00 UTC
Created attachment 93103 [details]
Output of qdbus org.kde.KWin /KWin supportInformation
Comment 10 Thomas Lübking 2015-06-10 14:40:53 UTC
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?
Comment 11 Fabian 2015-06-10 15:08:38 UTC
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.
Comment 12 Thomas Lübking 2015-06-10 15:18:16 UTC
You say you get flicker -with compositing suspended!- when changing the active window?
Comment 13 Fabian 2015-06-11 06:47:25 UTC
Yes, I just tested it again.

useCompositing: true
Compositing
Compositing is not active

and it flickers when switching windows.
Comment 14 Thomas Lübking 2015-06-11 12:51:04 UTC
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 &
Comment 15 Fabian 2015-06-11 14:27:06 UTC
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?
Comment 16 Thomas Lübking 2015-06-12 17:10:26 UTC
(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)
Comment 17 Fabian 2015-06-15 13:33:53 UTC
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).
Comment 18 Martin Flöser 2016-08-29 08:25:30 UTC
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.