[gcompris-devel] Performance issues

[Bruno Coudoin]

Le dimanche 07 octobre 2007 à 20:07 +0300, Terje Bergström a écrit :
> On Sunday 07 October 2007 17:08:16 Terje Bergström wrote:
> > So, the time is spent in gtk_widget_send_expose(). What does it do? Does it
> > call some callbacks in canvas where I could add more printouts?
> 
> During expose the actual drawing seems to be done. I'm getting a lot of time 
> spent in gnome_canvas_group_draw(), which is natural, as all items are part 
> of a group and that function draws them all.
> 
> I'm hitting a dead end here --- it is the actual drawing which uses the whole 
> time and so far I haven't seen any refresh delays etc. that I could blame for 
> this. 
> 
> I guess reducing the number of items to be drawn is the next logical choice.

Well, the time is probably spent in the rescaling of the image. Our
native resolution is 800x600 and you resolution is lower. What happen is
that we load the image as a pixbuf at it's native resolution then the
canvas rescale it at the display ratio.

I am currently investigating how we could benefit from the good svg
support we have now with librsvg and cairo. One option would be to use
librsvg to load svg images (rsvg_handle_new_from_file) and pass them to
the canvas item through a new rsvghandle property. In the pixbuf canvas
item we would use the rsvg handle and cairo to resize the SVG directly
instead of a pixmap.

For large items with low complexity like the confirm dialog background,
we can believe it's faster to redraw it smaller or bigger than resizing
a pixmap.

To confirm the resizing of a large image is the root cause, can you try
to remove the display of help_bg.png in gcompris_confirm.c.

-- 
Bruno Coudoin
http://gcompris.net Free educational software for kids
http://toulibre.org Logiciel Libre à Toulouse