Workaround for crashing when many tooltips are shown consecutively#563
Workaround for crashing when many tooltips are shown consecutively#563flodavid wants to merge 2 commits intoelementary:mainfrom
Conversation
36e88cc to
4fc351d
Compare
|
I moved the code to |
4fc351d to
5c5b953
Compare
src/BaseItem.vala
Outdated
| this.wait_and_show_tooltip (100); | ||
| }); | ||
| motion_controller.leave.connect (() => { | ||
| this.waiting_to_open_tooltip = false; |
There was a problem hiding this comment.
Probably you can use GLib.Source.remove () instead of a normal flag?
There was a problem hiding this comment.
You are probably right. I will do that soon
There was a problem hiding this comment.
Is this what you had in mind ? b6968f1
Edit: I removed open_tooltip_timeout_id = 0; in leave () since I assume leave () cannot be called twice without enter () being called in between and the ID being modified by it. Is it safe to assume or am I risking race condition ? Even then, the event ID would need to be reassigned to another event for it to cause a problem. Is this enough to justify not needing the reset ?
29b7319 to
9ed958f
Compare
9ed958f to
b6968f1
Compare
|
I think the pipeline is not failing because of the modification in this PR, as it also fails in another PR. and it is unrelated to my edits. |
Add delay of 100ms before showing dock tooltips:
Fixes #559. After researching it, the culprit seems to be the Nvidia driver, which causes a problem with GTK.Popup, which is used as tooltips when hovering launchers in the doc since #441.
Adding a big enough delay before showing the tooltip seems to prevent the error (or at least making it very unlikely). I tried 1ms and it seemed to reduces the crashes quite a bit already, but I succeeded with 50ms by increasing the pointer speed, so I set it to 100ms.
This can also have a positive side effect: When rapidly hovering the launchers, every tooltip were briefly shown, but not long enough to be readable. So the delay makes it less distracting a restores the behaviour before #441.
I only added the delay to the. Feel free to rework the PR or close it to implement a cleaner fix. Maybe a proper fix should be added to GTK, but a simple workaround by adding a delay like here would not be acceptable I guess.Launcherclass, and not the parentBaseItem