207abe9a2c
Tweener uses a clutter timeline to manage all active animations running at a given moment. The timeline is mopped up when no animations are going any more. Clutter requires timelines to have a finite duration, but since animations can happen at any moment, no fixed duration can accomodate the shell's needs. To combat this problem, the tweener code picks a relatively long duration: 1000 seconds. No string of animations should take that long, so, in theory, that should be good enough. Unfortunately, this tactic fails, in practice, when the user suspends their machine, or VT switches. An animation can take much longer than 1000 seconds (~16 minutes) to complete in those cases. When the user resumes, or VT switches back the timeline completes immediately (since it's already late) and tweener never notices that the timeline stops ticking. This commit changes the tweener timeline to automatically loop back to 0 after completing, so that despite its fixed duration property, it effectively never stops. Since the timeline loops, its concept of elapsed time no longer increases monotonically, so we now ignore it and track time ourselves with GLib.get_monotonic_time(). This partially reverts commit 35764fa09e4341e79732409c4e74c226d19f780f. https://bugzilla.gnome.org/show_bug.cgi?id=653833