Opened 14 years ago

Closed 12 years ago

#2080 closed defect (fixed)

Pulsing icon delayed by 5 seconds or so

Reported by: bernie Owned by: aa
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: 0.88.x
Severity: Unspecified Keywords: dextrose sugar-love
Cc: km0r3, aa, smparrish, mtd Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

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 .

Attachments (2)

0001-Pulsing-icon-delayed-by-5-seconds-or-so-SL-2080.patch (2.1 KB) - added by anurag_seeta 13 years ago.
shell.log (52.2 KB) - added by anurag_seeta 13 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 14 years ago by bernie

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

comment:2 Changed 14 years ago by bernie

This also affects sugar-0.84

comment:3 Changed 14 years ago by bernie

  • Keywords dextrose added

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.

comment:4 Changed 14 years ago by dfarning

  • Keywords sugar-love added

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by 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.

comment:8 Changed 13 years ago by smparrish

  • Cc smparrish added

comment:9 Changed 13 years ago by smparrish

  • seeta_dev set to Anurag

comment:10 Changed 13 years ago by anurag_seeta

r?

Changed 13 years ago by anurag_seeta

comment:11 follow-up: Changed 13 years ago by 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.

comment:12 in reply to: ↑ 11 Changed 13 years ago by 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?

comment:13 Changed 13 years ago by mtd

  • Cc mtd added

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.

comment:14 Changed 13 years ago by 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

comment:15 Changed 13 years ago by 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.

comment:16 follow-up: Changed 12 years ago by godiard

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

comment:17 in reply to: ↑ 16 Changed 12 years ago by bernie

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.