[Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
anurag at seeta.in
Fri Oct 29 14:39:53 EDT 2010
Uptill now what we have gathered from this issue is:
1) We can improve this issue by using a cache system or cairo operation:
> " I think the problem is the code is rendering the svg icon every time
> the color is changed.
> There are not cache or cairo operation used to avoid this.
-- I think that we all seem to agree upon this point that using a
cache to store the once rendered frames and then reuse them later
in the animation to improve the performance of the system.
2) We can change the pulsing icon animation to an alpha pulsing icon:
> " Not sure if we are doing right thing by trying to fight w/
> what about pulsing by alpha channel (ie w/o re-rendering svg). It might
> be used only on restricted systems like XO (though I don't see problems
> to do the same in all cases).
-- Looks like a very feasable idea and can potentially reduce the
loading time of the pulsing icon and eradicate the issue.
3) We can try some tweaks to the animation and related aspects of the
issue to make the animation smoother and lighter on
> "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).
--But we realised that any changes made to improve the animation were
not affecting the initial starting time , which is our main
point of concern.
4) Prerendering the pulsing icon and maintaining a cache (As said
earlier in point #1 also) type scenario for the different frames of
the animation also looks like a plausible option:
> "Yes, I think you're right, pre-rendering, either to RAM or to a file on
> disk, would likely speed things considerably.
> I suggest rendering 12 views at linear levels, then switching between
> them using varying timing rather than fixed timing. The visual effect
> would not appear to be different.
> --James Cameron"
--We can certainly try this option as it can possibly solve the
problem to a large extent and improve the system performance.
Also I would like to thanks everyone for their valuable pointers on
the issue uptill now which has enabled us to draw many conclusions
about the issue and cleared many doubts.
Also special thanks to Martin Dengler and James Cameron for performing
on the issue and providing us with valuable data for further research.
And thanks to Gary Martin for trying out my patch and giving a positive review
> "Have been tinkering here also. My best guess so far is that it is the zoom PLUS pulse effect precessing that is snagging things > up, but I'm still trying to nail it down for sure. Using the Distance dolphin SVG (fairly detailed) on an XO-1 F14 0.90 build I see a > launch delay of 4sec drop to 1sec (an eye ball test from home view activity icon click to first draw of the SVG). Now the patch
> needs work**, and is likely a quick fix for a deeper animatior issue, but it does do what Anurag has been saying it does.
> --Gary Martin "
On Fri, Oct 29, 2010 at 9:48 PM, Gary Martin <garycmartin at googlemail.com> wrote:
> On 29 Oct 2010, at 09:12, Martin Dengler <martin at martindengler.com> wrote:
>> On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
>>> I think the problem is the code is rendering the svg icon every time
>>> the color is changed.
>> Indeed. As James Cameron pointed out, we're setting the stroke and
>> fill in rapid succession, resulting in two calls to render().
>>> There are not cache or cairo operation used to avoid this.
>> Perhaps CanvasIcon's _emit_paint_needed_icon_area can check some
>> dirty flag that gets reset upon paint()? I'm not an expert, and it
>> sounds like there might be lots of races to worry about.
>> However it's easier just to replace the calls to set_stroke_color() and
>> set_fill_color() with set_xo_color(), which does both and then calls
>> So I did that, and using a small script to just launch the
>> pulsing icon window using the sugar emulator, we can compare before
>> and after: The code change halves the number of times we call
>> _emit_paint_needed_icon_area, and that is borne out by the experiment:
>> _emit_paint_needed_icon_area is called 196 times in 10 seconds before
>> the patch, and 99 times afterwards. Correspondingly, render_cairo()
>> is called half as much.
>> I'd love any feedback.
> I've been testing this patch on an XO-1 F14 0.90 build today and can confirm the svg icon appears in the launcher about one second after starting/resuming an activity from the home view. Fab! :)
> It's worth a note that the zoom in effect is still lost for most svg icons, only for the very simple icons is the effect visible (Log icon is simple enough to show it, Distance icon is not quick enough). The zoom animation is defaulting to 20 fps which can't be helping, but lowering it to 10fps doesn't seem to help enough to make much of a visible improvement. I only reliably started to see the zoom when I also increased the length of the zoom effect from 1sec to 2sec by modifying launcher.py #116:
> self._animator = animator.Animator(2.0, fps=10)
> ...so I guess that first second of launching is still rather swamped so the first second of zoom is usually skipped. Hmmm, maybe the zoom start should be triggered only once the first update has hit.
>> 1. http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-set-new-colors-in-one-go-to-avoid-multiple-calls-to-SVG-rendering.patch
>> 2. http://www.martindengler.com/tmp/sl.o-2080/profile-pulsingicon.py
>> 3. http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph-before.png
>> 4. http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph-after.png
More information about the Sugar-devel