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

[Anurag Chowdhury]

Thanks for your timely feedback. Appreciate it.

Also can you please review my patch for the following issue for conceptual
or logical flaws which i can't figure out after getting a positive response
from the benchmark logs of my solution . I have attached the logs which give
benchmark data of the pulsing icon as tested on a XO-1.5 .
In my logs I noted an average processing time of 0.85 sec  for running the
first run of the update () function (i.e. while rendering of the first frame
) and since a XO-1.5 is nearly 2.5 times faster than a XO-1 so this
processing time would approximate to nearly 2.3 second of delay , so if we
skip the update function for the first frame then we can speed up the
pulsing icon by nearly 2 seconds and I guess that is a considerable amount
of reduction in delay to start with. I tested this timer benchmark on the
Turtle art activity.

Regards,
--Anurag

On Sun, Oct 24, 2010 at 11:17 PM, Gary Martin <garycmartin at googlemail.com>wrote:

> 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).


> Regards,
> --Gary
>
> >  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20101025/cb01639d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shell.log
Type: application/octet-stream
Size: 53417 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20101025/cb01639d/attachment-0001.obj>