Pulsing icon delayed by 5 seconds or so

[bernie]

When starting an activity in 0.88, the launcher with the pulsing icon is sometimes delayed by a few seconds, during which you only get to see a white window. The sugar-session process seems to eat 100% cpu during this time.

Very rarely, the launcher would not come up at all and the activity will remain in its own frame. After you quit the activity, the pulsing icon finally appears! Eventually, the launcher times out and you get the new activity startup failure message with the close button.

I suspect the above bugs might have been caused by the patch for #1447 .

[bernie]

Tested on F11-0.88 build os300py. Can't reproduce it in jhbuild.

[bernie]

This also affects sugar-0.84

[bernie]

The delay appears to be proportional to the icon complexity: very short for Calculate, very long for TurtleArt.

The delay occurs when the icon should have been zooming in instead. The zooming effect is not visible on the XO-1. If I comment out zooming, the icon appears immediately.

[bernie]

I suspect the XO-1 is not fast enough to compute the frames of this animation as fast as needed (default fps=20), so it spins without ever reaching the idle loop.

Rather than establishing a-priori fps, we should let the animation fps degrade as the machine gets slower (or the task gets more complex). This could be easily achieved by setting a *fixed* delay after drawing each frame.

[bernie]

Even better approach: if Animator detects that the time elapsed between one frame and the next is too long for a decently fluid animation (say, more than 0.250ms), it immediately warps to the last frame.

[bernie]

Pointers to source code for developers unfamiliar with the Sugar codebase:

• sugar-toolkit: sugar/graphics/animator.py: class Animator._next_frame_cb()

This is where the animation frames are being computed. The actual animation happens by invoking user defined callbacks on each frame.

• sugar: jarabe/view/launcher.py: class LaunchBox.init()

This is where the animation is started. Try experimenting with different values of duration and fps to test my theory that the XO-1 is simply too slow to render the frames and does never enter the idle loop in which Gtk performs repaints.

[anurag_seeta]

r?

[anurag_seeta]

I have attached the shell.log file, in this ticket, created on my 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.

[bernie]

Replying to anurag_seeta:

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.

1. Why is the first frame slower to render than the others?
2. What changes with your patch applied?

[mtd]

A test harness is at  http://www.martindengler.com/tmp/sl.o-2080/profile-pulsingicon.py . I haven't tried it on an XO, but it might work.

[mtd]

Anurag has created a wiki page to track the history of this ticket:  http://wiki.sugarlabs.org/go/Pulsing_icon_delayed_by_5_seconds

[mtd]

Gonzalo's original patch is at  http://dev.laptop.org/~gonzalo/alpha-pulsingicon/ , and I've updated the wiki page to reflect that this is the preferred solution.

[godiard]

Can we close this ticket? The startup animation changed is already in sugar.

[bernie]

Replying to godiard:

Can we close this ticket? The startup animation changed is already in sugar.

Yes, it seems to work much better now (but has anyone measured, just for curiosity?)