[sugar] Need guidance from a Pygtk guru
Erik Garrison
erik
Tue Oct 7 10:30:09 EDT 2008
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
More information about the Sugar-devel
mailing list