Hi, I was tempted to re-open this bug report i started a while ago: https://bugs.kde.org/show_bug.cgi?id=307112 It seems "related" to that, but toggling "Save intermediate rendering results" doesn't influence this issue at all. Therefore i opened a new issue instead of re-opening the older one. When you hover over something that shows a tooltip the first time the tooltip is shown it's rendered a bit weirdly. It ends up being correct, but you definitely see render issues. Any subsequent hovering on the same area (to spawn the same tooltip) end up in a neat perfectly looking tooltip, no render issues. I'm attaching a video that shows the exact issue quite clearly. Reproducible: Always Steps to Reproduce: 1. hover something that shows a tooltip (chromium in the taskbar works quite well as example). 2. watch the tooltip appear with rendering issues. It ends up being correct, but the way from no tooltip -> tooltip fully visible is definitely not without issues. 3. Move your mouse away (so the tooltip fades away) 4. Hover the same area again, now the tooltip fades in just fine KWin output when starting it: --------------------------------------------- kwin_core: Initializing OpenGL compositing kwin_core: Choosing GLXFBConfig 0x115 X visual 0x2b depth 24 RGBA 8:8:8:0 ZS 0:0 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 670/PCIe/SSE2 OpenGL version string: 3.1.0 NVIDIA 352.09 OpenGL shading language version string: 1.40 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 352.9 GPU class: Unknown OpenGL version: 3.1 GLSL version: 1.40 X server version: 1.17.1 Linux kernel version: 4.0.4 Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no Direct rendering: true kwin_core: Initializing fences for synchronization with the X command stream kwin_core: Color correction: false kwin_core: 0x20071: Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use SYSTEM HEAP memory as the source for buffer object operations. kwin_core: 0x20071: Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) has been mapped WRITE_ONLY in SYSTEM HEAP memory (fast). kwin_core: OpenGL 2 compositing successfully initialized kwin_core: Vertical Refresh rate 60 Hz ( "primary screen" ) kf5.kservice.sycoca: Trying to open ksycoca from "/home/mark/.cache/ksycoca5" Using FBConfig 0x1a8 for visual 0xc4 kwin_core: 0x20071: Buffer detailed info: Buffer object 2 (bound to GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations. Using FBConfig 0x119 for visual 0x2d QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1766, resource id: 0, major code: 14 (GetGeometry), minor code: 0 QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1768, resource id: 0, major code: 14 (GetGeometry), minor code: 0 QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1769, resource id: 0, major code: 14 (GetGeometry), minor code: 0 QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1770, resource id: 0, major code: 14 (GetGeometry), minor code: 0 QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1771, resource id: 0, major code: 14 (GetGeometry), minor code: 0 QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1776, resource id: 0, major code: 14 (GetGeometry), minor code: 0 kwin_core: screens: 2 desktops: 1 kwin_core: Done. Using FBConfig 0x119 for visual 0x2d Using FBConfig 0x1a8 for visual 0xc4 kwin_core: Successfully loaded built-in effect: "blur" kwin_core: Successfully loaded built-in effect: "contrast" kwin_core: Session path: "/org/freedesktop/login1/session/c2" kwin_core: Successfully loaded built-in effect: "dashboard" kwin_core: Successfully loaded scripted effect: "kwin4_effect_login" kwin_core: Successfully loaded built-in effect: "desktopgrid" kwin_core: Successfully loaded scripted effect: "kwin4_effect_windowaperture" kwin_core: Successfully loaded built-in effect: "highlightwindow" kwin_core: Successfully loaded scripted effect: "kwin4_effect_translucency" kwin_core: Successfully loaded built-in effect: "kscreen" kwin_core: Successfully loaded scripted effect: "kwin4_effect_dialogparent" kwin_core: Successfully loaded built-in effect: "logout" kwin_core: Successfully loaded scripted effect: "kwin4_effect_maximize" kwin_core: Successfully loaded built-in effect: "magiclamp" kwin_core: Successfully loaded scripted effect: "kwin4_effect_fade" kwin_core: Successfully loaded built-in effect: "presentwindows" kwin_core: Successfully loaded built-in effect: "screenedge" kwin_core: Successfully loaded built-in effect: "screenshot" kwin_core: Successfully loaded built-in effect: "slide" kwin_core: Successfully loaded built-in effect: "slidingpopups" kwin_core: Successfully loaded built-in effect: "startupfeedback" kwin_core: Successfully loaded built-in effect: "zoom"
Created attachment 93049 [details] video that shows the issue
The tooltip isn't faded in and initially contains (apparently) uninitialized/old data. Can you check the behavior w/ compositing suspended (of course the tip won't fade in, but we could determine whether the garbage data is in the client or the compositor) @Mark, was that konsole window still open when you caused the tooltip or did you recently close it?
(In reply to Thomas Lübking from comment #2) > The tooltip isn't faded in and initially contains (apparently) > uninitialized/old data. > Can you check the behavior w/ compositing suspended (of course the tip won't > fade in, but we could determine whether the garbage data is in the client or > the compositor) Ok, will do so and report back later. > @Mark, was that konsole window still open when you caused the tooltip or did > you recently close it? Konsole was open all the time, i didn't close it somewhere in between. Small piece of info i forgot to mention that makes it easy to reproduce. If you take the steps i provided and just execute "killall plasmashell && plasmashell" (so restart plasmashell) as "step 0". Right after that you hover over something that shows a tooltip and voila, render issue. But it only happens once on each unique tooltip so you have to restart plasmashell every time when you want to see the glitch again.
(In reply to Thomas Lübking from comment #2) > The tooltip isn't faded in and initially contains (apparently) > uninitialized/old data. > Can you check the behavior w/ compositing suspended (of course the tip won't > fade in, but we could determine whether the garbage data is in the client or > the compositor) -- tried it -- With and without compositing, The exact same happens only without blur ;-) I did find something else though, without compositing the icons in the panel are really tiny! No i'm not in a QHD monitor, I will report a separate bug for that.
(In reply to Mark from comment #4) > With and without compositing, The exact same happens only without blur ;-) Client "bug" - the actual bug is probably in QML, though the situation isn't that simple. Usually clients set up and (in case they're managed) send a sync request when they're done. If they're not managed, the kwin compositor "covers" that by waiting 50ms before actually rendering them. So what happens here is that the window gets mapped with uninitialized content (bad) and initialization takes that long (bad) that it's exposed to the user. Unfortunately, this seems like a pattern with QML windows (we got bug reports for slow invocation of presentwindows and desktopgrid effect because of this), so they're basically not suited to get created "on the fly" The solution we took in kwin effects was to not recreate them (so only the first invocation is slow) - for the panel tooltips, one might resort to initially create the window once off-screen (they're hopefully unmanaged again?), then unmap them and from then on just re-map the window (what should be fast)
I'm quite sure that the task manager isn't the one to fix this. The tooltip component is a generic one if i recall correctly. I've shown it on the taskmanager because it's most visible there, but it's in all places that have this tooltip (clock, kickoff, etc..).
(In reply to Mark from comment #6) > I'm quite sure that the task manager isn't the one to fix this. The tooltip The component to *fix* this is QML. The workaround suggested however involves client logic (pre-init the tooltip offscreen) what cannot be performed by the tooltip itself :-(
So everyone that uses this tooltip should implement client logic to prevent the bug i've shown in the video from occurring? Ouch! I don't buy the argument of QML is the one that needs fixing (QML is the language, QtQuick is the toolkit, i suppose you meant QtQuick). QtQuick has the Loader{} component which should be sufficient for what you propose. Then it's up to the "tooltip" component (don't know if that's the name) to fix initial loading case. Surely you can detect - in the tooltip C++ side - if the component is in initial loading state? You can probably even use the tooltip constructor for that. Or do i misunderstand something now?
(In reply to Mark from comment #8) > So everyone that uses this tooltip should implement client logic to prevent > the bug i've shown in the video from occurring? Ouch! > > I don't buy the argument of QML is the one that needs fixing (QML is the > language, QtQuick is the toolkit, i suppose you meant QtQuick). Whether language or interpreter, maybe even the plasma componets (loading & rendering svg or so): whatever is to blame that a) creating a QtQuick/QML window is dead slow (on the main thread!) b) it maps before the scene is at least basically initialized needs to be fixed. Granted: the ToolTip *could* detect the first show (internally it uses some static Plasma Dialog QQuickWindow) event and show it offscreen, wait 1-2 seconds, then hide it and show it in the desired position, but a) that's just moving the workaround b) that may induce further problems (ugly workarounds go into client code, not library code) in case the client simply expects that "map here" means "map here" and not "first map over there, then here a little later") - alternatively the tooltip had to block on first invocation (and by a timer...).
Please let us know if this is still an issue with 5.6 beta or later, as there were many, many changes to tooltips.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!