On Sun, 2010-10-24 at 18:47 +0100, Gary Martin wrote: > 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.
The actual problem is that rendering complex svg icons takes so long on the XO-1 that when we exit from the update hook, it's already time to render the next frame. Thus, the event loop never goes idle, which is where gtk normally updates the display. A possible workaround consists in adjusting the frame rate dynamically in the Animator class, based on how long it took to render the previous frame. It's a simple technique used by video players and games. It shouldn't take more than 2 lines of code, but I can't predict how well it will work in this case, because from Anurag's measurements it looks like it would take several seconds on the XO-1 to render just one frame of the animation. If this turns out to be true, we might want to completely disable both zooming and flashing on machines that are obviously too slow to support it decently. > 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). The bug also occurs in F11, with Dextrose 2 and OLPC OS 10.2.1. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
