>> does anyone know if this has been fixed in the latest Canvas/libart >> code, or is this one of those performance features that wasn't noticed >> because nobody anticipated such huge (wide) canvas items? > >Probably no one's ever tried it. Most likely whatever O(n) (or worse) >mess is causing this is also slowing down common cases though, so >worth filing a report and/or investigating.
turns out that its not in libart_lgpl at all. even my "simplerect" that just paints a rect directly into the canvas RGB buffer can be induced to suffer the same performance problem. it doesn't happen as often, but it still happens. so it has more to do with the Canvas's tiling (uta) algorithms used during an expose event and/or GTK idle callbacks. i'm doing more checking with gdb etc. to figure out where the bottleneck is. --p _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
