[Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
garycmartin at googlemail.com
Sun Oct 24 13:47:20 EDT 2010
On 24 Oct 2010, at 16:53, Anurag Chowdhury wrote:
> The present issue has two possible scenarios of solving it
> 1) Optimise the present pulsing icon animation to reduce the delay : Thats what I have worked towards till now in my patches.
> 2)Replace the present pulsing icon animation with a better and faster animation: Thats what I think everyone agrees to be the best solution of the issue right now.
-1 from a Sugar design point of view. The zoom animation is part of the Sugar views zoom metaphor as you move from level to level (neighbourhood --> group --> home --> activity). The pulsing is an indication that the activity is still starting (unspecified/unknown amount of time hence no scroll bar, clock dial, or such quantitive measure of completion). Ideally, if launching were less than a few seconds we would not have needed the pulsing animation.
We did play around with a few ideas when Wade last worked on the pulse optimisation/enhancements. He landed improvements for speed by minimising the area being redrawn, and landed the addition of the "failed to launch" check and button/message. He also found a few extra cpu seconds worth of improvement that didn't land in time. The trick was to fade in, _hold_, fade out, _hold_, the effect is still of pulsing activity but you can get away with less frames as you don't need to redraw anything during the hold.
This doesn't effect the initial start-up however, which I believe was the original ticket... FWIW I think F14 builds have regressed for some other reason here, perhaps it's the window manager being laggy (I occasionally see window bezels before things go full screen).
> If we're still taking about the v5 patch that was posted to the list, I
> don't understand how this change is supposed to fix the bug:
> + if self._count > 2:
> + self.update()
> + self._count = self._count + 1
> The animation of the pulsing icon is basically constituted by filling the raw svg icon with colours based on a sinusoidal function
> and it is this sinusoidal filling of the colour that brings about the pulsing effect , so if we dont fill the icon with colour then
> the icon wont pulse and would render and appear as a raw svg icon only which undoubtedly will take lower system resources
> to get rendered than the animation.
> Skipping the first frame of the animation unconditionally is wrong and
> isn't the same thing of skipping frames dynamically, based on the time
> elapsed to render the previous frame. I feel like we're trying a number
> of random tweaks without addressing the root cause of the problem.
> The first frame of the animation is not being skipped but its just not being filled with colour so as to make the pulsing icon animation start earlier and I hope we both agree on the fact that the delay is caused due to the time taken for the rendering of the zoom in and zoom out animation for the first frame. So if the load of processing the first frame would have been reduced somehow then the animation would start earlier and this approach was confirmed by positive log results upon benchmarking the whole scenario before and after the fix.
> Perhaps Anurag could work on a fix in team with other Seeta developers?
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
More information about the Sugar-devel