| Summary: | Tooltip renders weird on first show, looks good on subsequent ones. | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Mark <markg85> |
| Component: | Task Manager and Icons-Only Task Manager widgets | Assignee: | Eike Hein <hein> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | plasma-bugs-null, thomas.luebking |
| Priority: | NOR | Keywords: | triaged |
| Version First Reported In: | 5.3.1 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | video that shows the issue | ||
|
Description
Mark
2015-06-07 11:21:55 UTC
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! |