Another thing that is insane is to have a theme-api which requires a GdkDrawble. Non-GTK apps like Firefox, QT or Java have to allocate small pixmaps, ask GTK to render to that *twice*, and read back from the X-Server - leading to thousands of unnesscesary context switches and GPU stalls slowing all non-gtk apps down a lot that want to use gtk's theme. I started working on improving the theme engine back in early 2008 in a way that would allow "old" themes to still work without changes, nobody looked at it, even after asking on the mailing list. Later on I got told all that will be solved in GTK3. Well yes, ohm ... GTK3 ... to be released ... when ... and used by whom? Even Shuttleworth would like Gnome to use QT. On one side GTK is still *the* toolkit in the open-source world, on the other side it seems to be completly stuck in the last few years. What was the last exciting improvement? Was it cairo integration back in GTK-2.8? My code may be bullshit, and I would have accepted it and rewrote it. By the way, I am still interested in re-working the theme API. So if you would know somebody which could review my patches, I would be happy to work on it of course. - Clemens > It's pretty convenient for you to call implementations "insane" and that > nobody reviewed your patches before flat out rejecting them - all without a > link to the bugzilla entry or the mailing list discussion. That was years ago. (2006?) Isn't it insane to allocate 15mb of temporary pixmaps, juts to paint the main-window of gftp a single time? And that was on a 1024x768 screen. No wonder it ressizes slow, and nvidia went crazy implementing fast-paths for pixmap allocation. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
