Hi David, > I did my part by SUBMITTING BUG REPORTS, several in fact.. > I'm an not a GTK+ wizard, nor do I know all the intricacies about > how it renders. hence I GAVE them the information ,described the > problems, and it was tossed out. <ironic> You should better not post/ask/report about performance problems with GTK+. For some unknown reason many developers don't talk about this, its some kind of taboo. So be everybody's friend here just send a message to the list saying that GTK is wonderful and fast. </ironic> A lot of GTK+ performance problems accumulate: * GLib's object system: Written in plain C. A simply typecast in Java costs typically 1cycle (for classes) or about 100 in the worst case (for some special cases with interfaces). Look at GLibs typecast code and you'll understand ... countless cycles :-/. I've seen code spending 3% of time in casts (oprifile)! The typecast-stuff is just an example, but I don't think its a lot different in other areas. * No performance monitoring: Unlike many other projects GTK+ does not have any performance regression testing. Small regressions accumulate over time and nobody notices. * Unoptimized drawing: GTK allocates a pixmap for every sub-window which is repainted (typically about 100's for larger apps), draws into it a singly time and throws it away again. Not funny. * Typical performance bugs: Like the one you are seeing. Nobody tries to fix, most work arround, others produce slow apps. lg Clemens _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
