[Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[David Farning]

Congratulations -- and welcome to the world of hacking:)

This email represents the crux of problem solving.

All of the git, python, pep8, variable name, stuff is just syntax and
semantics.  Important to follow or you get 'errors and warnings':)

At it's core 'hacking' is identifying and solving problems.

david

On Sun, Oct 24, 2010 at 10:53 AM, Anurag Chowdhury <anurag at seeta.in> 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.
>
>>
>> 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
> http://lists.sugarlabs.org/listinfo/dextrose
>
>