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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
