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

James Cameron quozl at laptop.org
Fri Oct 29 06:17:17 EDT 2010


On Fri, Oct 29, 2010 at 09:47:33AM +0100, Martin Dengler wrote:
> On Fri, Oct 29, 2010 at 10:56:25AM +1100, James Cameron 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.  There are not cache or cairo operation used to
> > > avoid this.
> > 
> > Now if these were filtered to a reduced set of levels, the rendered
> > images could be cached and re-used.
> > 
> > 	N = 10
> > 	self._level = int(math.sin(self._phase) + 1) / 2 * N) / N
> 
> I'm interested in what you mean here.  I applied this patch:
> ...and I didn't see much change with my test program[1]:

No, you would not.

My brief but syntactically incorrect code fragment was only to point out
the reduction in levels.  Instead of there being a unique value of
_level for each frame in the animation, there would be only one of N.

This is necessary for the images to be cached and re-used, but I didn't
describe the caching and reuse of the images.  Unfortunately I don't
know how to do that yet with GTK+ and the Sugar Toolkit icon.py, but I
don't imagine it will be difficult.  It would be like changing the icon
image, and we already have code that does that.

Here's how I did it on a pygame application, where an image represented
a spaceship in a 2D game, which had 256 possible angles of rotation,
which were reduced to just ten:

a.  the possible angles of rotation were reduced from one out of 256 to
one of 10, simply by dividing by ten and multiplying by ten, [1]

b.  the image (a PNG file) was read and rotated, then placed in a cache
indexed by the rotation value, [1] [2]

c.  repeated requests for the same image with an already cached rotation
were satisfied from the cache.

Now I know the launcher animation is not rotated, although that might be
a neat idea, but if the images at various _level values are cached such
that there are N of them in the cache, then they might be accessed in a
similar fashion.

N does not necessarily need to be 10.

The update frequency does not necessarily need to be 10 Hz, or fixed at
all.  I recall mentioning that earlier today in another post.

References:

1.
http://james.tooraweenah.com/cgi-bin/darcsweb.cgi?r=netrek-client-pygame;a=headblob;f=/netrek/__init__.py#l1192

2.
http://james.tooraweenah.com/cgi-bin/darcsweb.cgi?r=netrek-client-pygame;a=headblob;f=/netrek/cache.py#l41

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


More information about the Sugar-devel mailing list