Closed sniirful closed 4 months ago
What happens if the application is launched from another launcher or using the keyboard, is the forced-hover causing any side-effect?
What happens if the application is launched from another launcher or using the keyboard, is the forced-hover causing any side-effect?
I've tested it using a Fedora 39 virtual machine and launching the app both by pressing the Super key and typing the app name, and by pressing Ctrl-Alt-T after setting it as a keyboard shortcut in the settings: Screencast from 2024-02-16 15-57-15.webm Screencast from 2024-02-16 15-57-38.webm
I apologize for the videos appearing with weird coloring (maybe that's a virtio bug?) but you can still clearly see that the animation has the background blurry and it unblurs only when the animation finishes. It's a bit annoying but it's not as annoying as having it always blurry.
I'm still wondering if we can ever understand the root reason though :)
I'm not sure whether this issue can be attributed to how GNOME renders objects, it almost looks like it always keeps the same background resolution as the first frame it rendered. Since it renders the object by directly animating it, it looks like when it renders the first frame of the animation it doesn't bother to upscale it later. This might seem just an assumption but it can be verified by two tests:
Test n. 1: Change the show function so that it first renders the object without animation, then makes it disappear and then renders the animation. The object will be sharp 100% of the time. Result: Screencast from 2024-02-16 16-14-57.webm Code:
show(animate) {
if (this.child == null)
return;
let time = animate ? DASH_ANIMATION_TIME : 0;
// make it appear first
this.ease({
scale_x: 1,
scale_y: 1,
opacity: 255,
duration: 0,
});
// wait "time" ms and then make it disappear
setTimeout(() => {
this.ease({
scale_x: 0,
scale_y: 0,
opacity: 0,
duration: 0,
});
}, time);
// wait "time * 2" ms and then make it animate
setTimeout(() => {
this.ease({
scale_x: 1,
scale_y: 1,
opacity: 255,
duration: time,
mode: Clutter.AnimationMode.EASE_OUT_QUAD,
});
}, time * 2);
}
Test n. 2: To prove it's not a matter of just waiting, let's change it so that instead of animating the object instantly, it waits let's say for 1 second and then it animates. The object will be blurry just like it was before this change. Result: Screencast from 2024-02-16 16-20-09.webm Code:
show(animate) {
if (this.child == null)
return;
// wait 1 second and then animate
setTimeout(() => {
this.ease({
scale_x: 1,
scale_y: 1,
opacity: 255,
duration: animate ? DASH_ANIMATION_TIME : 0,
});
}, 1000);
}
The root cause seems to have been identified here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6567#note_2020532
The blurry issues seem to apply to the shutdown / reboot popup briefly, app icon backgrounds and desktop thumbnails.
When a new application is opened, the background usually results in being blurry, unless the mouse cursor hovers over the dash, just like in the following screenshots:
![image](https://github.com/micheleg/dash-to-dock/assets/45568396/6a2f82de-6a11-491c-9a30-c4c6258b732c)
Such a problem was already well documented in the issue #1722.
This pull request fixes this issue by overriding the show() method from DashItemContainer in DockDashItemContainer and simulating a hover over the item once the animation is finished.