[sugar] Need guidance from a Pygtk guru

[Erik Garrison]

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