Thanks for your timely feedback. Appreciate it.<div><br></div><div>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 .<br>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div>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.</div>
<div><br></div><div>Regards,</div><div>--Anurag</div><div><br></div></span><div class="gmail_quote">On Sun, Oct 24, 2010 at 11:17 PM, Gary Martin <span dir="ltr"><<a href="mailto:garycmartin@googlemail.com">garycmartin@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 24 Oct 2010, at 16:53, Anurag Chowdhury wrote:<br>
<br>
> The present issue has two possible scenarios of solving it<br>
><br>
> 1) Optimise the present pulsing icon animation to reduce the delay : Thats what I have worked towards till now in my patches.<br>
><br>
> 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.<br>
<br>
</div>-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.<br>
<br>
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.<br>
<br>
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). </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards,<br>
--Gary<br>
<div class="im"><br>
> If we're still taking about the v5 patch that was posted to the list, I<br>
> don't understand how this change is supposed to fix the bug:<br>
><br>
> + if self._count > 2:<br>
> + self.update()<br>
> + self._count = self._count + 1<br>
><br>
> The animation of the pulsing icon is basically constituted by filling the raw svg icon with colours based on a sinusoidal function<br>
> 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<br>
> the icon wont pulse and would render and appear as a raw svg icon only which undoubtedly will take lower system resources<br>
> to get rendered than the animation.<br>
><br>
> Skipping the first frame of the animation unconditionally is wrong and<br>
> isn't the same thing of skipping frames dynamically, based on the time<br>
> elapsed to render the previous frame. I feel like we're trying a number<br>
> of random tweaks without addressing the root cause of the problem.<br>
><br>
> 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.<br>
><br>
><br>
> Perhaps Anurag could work on a fix in team with other Seeta developers?<br>
><br>
> --<br>
> // Bernie Innocenti - <a href="http://codewiz.org/" target="_blank">http://codewiz.org/</a><br>
> \X/ Sugar Labs - <a href="http://sugarlabs.org/" target="_blank">http://sugarlabs.org/</a><br>
><br>
><br>
><br>
</div>> _______________________________________________<br>
> Dextrose mailing list<br>
> <a href="mailto:Dextrose@lists.sugarlabs.org">Dextrose@lists.sugarlabs.org</a><br>
> <a href="http://lists.sugarlabs.org/listinfo/dextrose" target="_blank">http://lists.sugarlabs.org/listinfo/dextrose</a><br>
<br>
</blockquote></div><br></div>