GNOME Bugzilla – Bug 683970
Animation from user to password prompt takes too long
Last modified: 2021-07-05 14:28:43 UTC
Using Debian Sid/unstable with GNOME Shell 3.4.2-1 and editing /etc/gdm3/greeter.gsettings to use gnome-shell instead of gnome-fallback as the session, my users are complaining that the animation after selecting a user to its password dialog takes too long. It is nice to see the first time but two seconds wait is too much. It would be awesome if there was a possibility to configure that or even disable it.
Please change `gnome-shell` to `gdm-shell` in my original report. /etc/gdm3/greeter.gsettings changed: [org.gnome.desktop.session] session-name='gdm-shell' [org.gnome.login-screen] logo='/usr/share/icons/gnome/48x48/places/debian-swirl.png' fallback-logo='/usr/share/icons/gnome/48x48/places/debian-swirl.png' [org.gnome.power-manager] icon-policy='never' [org.gnome.metacity] compositing-manager=false
This is tracked as bug #687573 [1] in the Debian bug tracking system. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687573
a big part of the problem here is we don't let the user start typing until the animation finishes. I think there's a bug already for queuing the key sequencies.
(In reply to comment #3) > a big part of the problem here is we don't let the user start typing until the > animation finishes. I think there's a bug already for queuing the key > sequencies. Definitely! Though I the input field only shows up at the end of the animation, so most users would probably not start to type.
Could you point me to a section of some design document, explaining the rules when animations are needed, please? As said earlier, I think in the end most (extensive) animations are not useful for the productivity of the user. That is also reason most people did not use the cube effect in Compiz when switching their virtual desktops.
Andre: I don't think it's a performance issue, it's really a design question.
In 3.4, there were two states: 1) expanded user list 2) shrunk password entry. The two states had dramatically different sizes so animation is the only way to prevent it from visually "popping" from one state to the next (which negatively affect the fluid aesthetics of the shell). In 3.6, there's no small box in the middle, so it's less of an issue. Th current design (which isn't fully implemented) is here: http://jimmac.fedorapeople.org/gnome3/login.webm In it you'll notice the animations are much shorter and the on screen objects don't move around as much. So when we fully implement that, this problem should improve.
Also see bug 681576
(In reply to comment #3) > a big part of the problem here is we don't let the user start typing until the > animation finishes. I think there's a bug already for queuing the key > sequencies. This has been fixed today, I think.
I think it was only fixed for unlock, though in bug 681576 there's talk about doing it for login screen too.
Could you please point me to the code line in 3.4.2 where I can configure this behaviour manually?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.