Add desktop style transition animation

[JoseExposito]

Description

Display a fade animation when the desktop style changes from default to dark or vice versa.

Notice that, because the theme changes at the GTK level, we need to wait an arbitrary time showing current theme window before we can perform the animation.

Caveats

The right solution for this problem is to implement this animation in the toolkit, however this is not possible for the moment.

The timeouts I used work as expected... on my hardware. I'd appreciate if you could test this in your hardware as well so we are confident that this is a good enough™ solution.

Demo

IN.mp4

[cassidyjames]

@JoseExposito this looks so good! It works well on most hardware here though setting the delay to 200ms seems to be more reliable in masking the transition on my i3 laptop.

On my Pinebook Pro, however… I have to set the delay to something pretty unreasonable like a full second to reliably mask things. Is there any way you can think of to dynamically scale that delay, e.g. to actually wait to see if the transition would be done and base it off that? Or maybe base it off the graphics memory available or something? Setting the delay that high on the Pinebook Pro still feels far superior to just watching the jank of a GTK transition happening in real time.

[marbetschar]

Can confirm its a much nicer transition on my Dell XPS 13 7390. But it seems there is some kind of stuttering/flickering/lag when changing from light to dark and vice versa.

However, from what I can tell this is only noticable for the System Settings app - not the other ones. Maybe its just the animation beeing a bit too fast and my eyes are not able to cope?

Screen.record.from.2021-09-02.12.50.32.mp4

[cassidyjames]

@marbetschar so in that case, the delay is not high enough and so you're seeing the GTK change slip through the animation. Try making the above suggested change and see if that works better for you.

[JoseExposito]

Hi guys, thanks for testing it on your hardware!

After your tests and a conversation with @Exalm on twitter -he mentioned 250 ms- I changed the value to 300 ms to be safe. It should work on most devices and it stills feels relatively quick.

Worst case scenario -similar to what Cassidy mentioned with the Pinebook Pro- the user won't show the animation... Just like it happens now.

On my Pinebook Pro, however… I have to set the delay to something pretty unreasonable like a full second to reliably mask things. Is there any way you can think of to dynamically scale that delay, e.g. to actually wait to see if the transition would be done and base it off that? Or maybe base it off the graphics memory available or something? Setting the delay that high on the Pinebook Pro still feels far superior to just watching the jank of a GTK transition happening in real time.

Quickly explaining how this works so its easier to understand what's going on: I take a snapshot of the window just before switching the stylesheet, draw it on top of the actual window and fade.

The answer to your question is yes, we could adjust the animation time based on CPU or similar. However, the problem with a long delay is that the UI is going to look unresponsive. Under the screenshot it'll react to mouse and keyboard events, but for the user is going to look freeze and suddenly animate to a different status.

A quick video with a 1 second delay showing what I mean:

a-quick-user.mp4

In my opinion, for a slow device like the Pinebook Pro, is better to not display an animation -like we do at the moment- than freezing/breaking the UI.

[cassidyjames]

@JoseExposito yep, I understand how the delay works, but mentioning accepting input is a good point. However, even on relatively good hardware I'm not seeing consistent GTK transitions in any predictable time; I had to crank it up to 700ms on my Star LabTop (which generally feels like a very speedy laptop!) when I have just a few windows open. So what I'm seeing with a lower delay is that the transition we crossfade to is this broken half-state, which in some ways looks worse than no transition at all.

This may be worth investigating on the stylesheet side as well in case we could improve how quickly things are transitioning there, but I feel that even with a 700ms delay and a 300ms transition (so 1 second total), the UI doesn't feel so unresponsive, and it masks the GTK transition I'm seeing almost every time. I think I'd like to try that and see how it feels across different hardware. Even playing video, that delay is apparent but doesn't feel totally unreasonable.

[cassidyjames]

As a note for my testing scenario, I'm using a page with this GitHub PR in Web, a Files window, and the System Settings → Desktop → Appearance pane. The Appearance pane is consistently the one I have issues with getting in under the time, possibly due to the illustrations being used there somehow slowing GTK down when transitioning. Regardless, that's the screen everyone is gonna see when changing the style, so we should kind of cater to it. ;)

[cassidyjames]

Just another stream of consciousness comment: shipping with a longer delay to start, then investigating and fixing any delays possible in the GTK transition itself, and then shortening the delay in Gala is also entirely possible. But I wouldn't want that other work to delay (ha) this initial PR.

[JoseExposito]

Ok, just updated the delay to 700 ms to make sure we all test the same code.

In @marbetschar's video I can see the issue you mentioned with the Appearance pane. I think you are right, the changes we make in the UI there might be causing issues, it's worth to investigate it.

[alice-mkh]

250ms was just as random as 100ms.

If you want my opinion - block transitions on the client side, then there's no need to do a delay in Gala.

[JoseExposito]

If you want my opinion - block transitions on the client side, then there's no need to do a delay in Gala.

As far as I know, we can not force gtk-enable-animations from the WM and, unfortunately, the API used to change themes is not encapsulated in Granite, so, the only option would be to force developers to change their code. Unfortunately, we can not follow that approach... At least until your changes in libadwaita get merged with that code in place ;)

Also, I've not tested it, but I think we'll have the same issues on slow hardware?

[alice-mkh]

Hmmm, I mean there is a system wide setting to block animations too. Although the question is how fast it gets propagated to clients as well.

Also, I've not tested it, but I think we'll have the same issues on slow hardware?

Yeah, although I heavily suspect GTK3 animations are one of the most expensive parts of this all.

[cassidyjames]

So poking at this further, the GSetting to disable animations doesn't seem to apply to CSS animations in the stylesheet. Forcing it in the stylesheet/app's custom CSS (e.g. with * { transition: none; }) seems to have a positive effect on the synchronizing (everything changes at once), but it still seems extremely unpredictable timing-wise. Sometimes it takes a few ms, sometimes there is a noticable delay (estimated in the hundreds of ms). So this makes me think:

• We can probably clean up transitions in the stylesheet itself to improve the synchronization, but I'm unsure it will actually speed up the transition
• We could ship the somewhat long delay in the meantime to paper over most cases
• Some sort of API in Granite or LibAdwaita or GTK itself would probably be ideal to get this right

[alice-mkh]

So poking at this further, the GSetting to disable animations doesn't seem to apply to CSS animations in the stylesheet

It most definitely does. That (well, the matching GtkSetting) is what I'm using in the libhandy and libadwaita branches.

But yes - there's a delay - GTK3 is unfortunately pretty slow when it comes to loading CSS and redrawing things.

[cassidyjames]

@Exalm what GSetting, then? Because setting the org.gnome.desktop.interface one doesn't change anything in Handy or Gtk.CSS animations for me here.

[JoseExposito]

Here is the implementation:
https://gitlab.gnome.org/GNOME/libadwaita/-/commit/47de1e9aa4f3b6001bbdbe7b199c573ce85c7617#ad9c43da9f097a3f58836a13ee14e24b45ae58a5_0_118

[alice-mkh]

@Exalm what GSetting, then? Because setting the org.gnome.desktop.interface one doesn't change anything in Handy or Gtk.CSS animations for me here.

That's the one. However, since you don't use gnome-settings-daemon, I can't confirm or not that it actually works in elementary, but it works in GNOME, so might need to plumb it in the settings daemon if it doesn't affect GTK.

Namely, on X11 GTK gets its settings from XSettings and settings daemon translates gsettings into those. It's same with fonts, etc. See https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/xsettings/gsd-xsettings-manager.c

[alice-mkh]

Here is the implementation:
https://gitlab.gnome.org/GNOME/libadwaita/-/commit/47de1e9aa4f3b6001bbdbe7b199c573ce85c7617#ad9c43da9f097a3f58836a13ee14e24b45ae58a5_0_118

That's client side AND that's GTK4 only. Though libhandy implementation is similar, it's not 100% same.

[cassidyjames]

@JoseExposito hm, I'm not sure if something changed underneath this branch, but now in its current state I get a pretty reliably weird transition:

2021-10-26.12-43-37.mp4

[JoseExposito]

@cassidyjames I think that the new FreeDesktop.org portal is enabled, isn't it?

Maybe this animation is not reliable enough with GTK 3 and we should wait for GTK 4...

[alice-mkh]

You need to first start animating, then change color scheme. Otherwise it will never be reliable.

In other words, it will have to be settings daemon or switchboard calling animate itself before changing it. Not gala listening to it.

GTK4 will make it worse because it's generally faster for things like this, and faster is exactly what fails here.

[JoseExposito]

Yes, I know, but we will still have issues on slow devices like the Pinebook Pro.

If we want to merge this PR knowing that those limitations are there, I don't mind adding the required D-Bus interfaces, but the solution is not going to be perfect...

[alice-mkh]

Slow devices would have the opposite problem - and I don't think you can fix that one. The one fast devices get is completely preventable though, but it does add complexity. :)

[alice-mkh]

Ok, so we ended up adding a delay in GNOME as well - 250ms. Oh well. :(