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

[Gary Martin]

On 28 Oct 2010, at 00:17, James Cameron <quozl at laptop.org> wrote:

> On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
>> I carried out the same benchmark test, which I earlier conducted on an
>> XO-1.5, on a XO-1.  And I have attached the log files obtained in both
>> the cases.
> 
> I have reviewed them.  Can you show me the patch you used for benchmark
> test?  I re-read the code from launcher.py, pulsingicon.py in sugar.git,
> down to icon.py in sugar-toolkit.git, but wasn't able to figure out
> where you might have added that benchmark timing.  Without it, I don't
> understand what you are measuring, and so I don't understand the result.
> 
>> And found my assertion of XO-1.5 being a faster system in parameters
>> of the pulsing icon rendering also i found out the delay of the first
>> frame to be nearly 1.5 secs on XO-1 as compared to 0.8 secs on XO-1.5.
>> also the consecutive times taken for the rendering of the frames on
>> the XO-1 were much larger as compared to that on a XO-1.5. 
> 
> Yes, it seems to be a CPU task, not a graphics task, that you have
> removed by your proposed patch.
> 
>> Hence, the above taken log results verify that XO-1.5 has better
>> system performance in case of graphic rendering than XO-1.
> 
> Graphics rendering, yes.  Graphics performance, no.  I'm so sorry, all
> this time I thought you were talking about graphics performance, but now
> I see you are addressing a graphics rendering issue.
> 
>> And shipping the update function call for the first frame reduces the
>> delay by nearly 1.5secs on an XO-1 and by 0.8 secs on XO-1.5.
> 
> So Bernie's questions in the bug spark my curiosity as well ... why is
> it that the first frame is slower to render than the other frames?

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.

**FWIW I'd use a Boolean flag _skip_first_update, rather than an int counter (also the test for >2 should have been either >=2 or just >1), and there's no need to calculate the phase and level until you are updating so those can go inside the test. 

> (An unrelated side-issue ... the launcher is stealing CPU cycles from
> the startup of the activity, the task run queue shows this during a
> launch.  I wonder if activities might start up faster if there was no
> launcher, just a busy cursor.)

The main issue was that kids quickly start clicking (and did!) on other visible buttons/activities, quickly stalling out the whole system through impatience. The fullscreen launcher was designed to remove this case given our multi second launch times.

Regards,
--Gary 

> -- 
> James Cameron
> http://quozl.linux.org.au/