[sugar] Need guidance from a Pygtk guru

[Pierre Métras]

On Tuesday 07 October 2008 10:30, Erik Garrison wrote:
> On Sun, Oct 05, 2008 at 10:19:20AM -0400, Pierre Métras wrote:
> > Hello,
> >
> > I've learnt Python and Pygtk writing the Clock activity
> > (http://wiki.laptop.org/go/Clock_activity) and I'm now adding a new
> > feature to write the time in full letters to help children learn how to
> > write and read it. The clock has different display modes and the default
> > one is to use a SVG background. I encounter a strange behavior and I
> > don't know where to look at to correct it.
> >
> > The display of the clock activity is composed of a gtk.VBox with a custom
> > ClockFace widget at the top, and a gtk.Label where I write the current
> > time. The user can decide to hide/show the written time with an icon in
> > the toolbar.
> >
> > When the Label is not displayed, the XO has enough power to update the
> > ClockFace widget in less than 1 second, which is nice and what you would
> > expect from a clock with a hand for seconds.
> >
> > But when the user selects to show the time and the code show() the
> > gtk.Label, the ClockFace widget takes more than 1 second to refresh. The
> > whole activity becomes unresponsive and it is even difficult to move the
> > mouse to close it. Gtk timer event every seconds can't follow up...
> >
> > I've tracked the problem to these lines:
> >
> >            if radius != self._cache_radius:
> >                 f = open("clock.svg", "rb")
> >                 svg_data = f.read()
> >                 f.close()
> >
> >                 loader = gtk.gdk.PixbufLoader("svg")
> >                 loader.set_size(int(2 * radius), int(2 * radius))
> >                 loader.write(svg_data)
> >                 loader.close()
> >
> >                 self._cache_pixbuf = loader.get_pixbuf()
> >                 self._cache_radius = radius
>
> Combining the above code block and the following observation ...
>
> > As I've said, this strange behavior seems to occur only when the
> > ClockFace widget paints SVG. In the other display modes, the painting is
> > drawn in the code. I've seen it in 8.2-761 and still in candidate-767.
>
> ... I suggest that the problem may have something to do with file IO.
> Are you doing this work on an XO?  At present its filesystem has
> *extremely* poor performance and I would be unsurprised if the described
> latencies were incurred in opening and reading even a small SVG file.
>
> Erik

Thanks for your help. The SVG file is cached in a Pixbuf and is reloaded only 
when I thought it was necessary (screen rotation or text label displayed).
In fact, a bug has been opened on a similar problem with my Clock activity and 
Scott Ananian pointed me at some code which uses double buffering with 
Pixmaps to paint a SVG out screen, instead of drawing explicitely. I'm going 
to rewrite this part of the code with similar technics and make it simpler. I 
hope I'll be able to optimize the activity for XO resources.

-- Pierre Métras