| |||||||||||||
|
| |||||||||||||
any detailed info on GTK+ plans?any detailed info on GTK+ plans?Posted Jul 29, 2008 23:14 UTC (Tue) by mmarsh (subscriber, #17029)In reply to: any detailed info on GTK+ plans? by oak Parent article: GNOME 3.0 worries
No. The article mentioned cruft, and it's a natural assumption that there's likely to be speed gains in ditching it. How much -- who knows? Not having to maintain backwards compatibility means that developers can focus on other things, and it's difficult to predict what those gains might be. Efficiency isn't an unreasonable guess. Honestly, the only speed impact I really notice from GTK+ is when firefox is rendering a particularly complex web page in a backgrounded tab, bringing the current tab essentially to a halt. That's not too frequent an occurrence, though.
(Log in to post comments)
any detailed info on GTK+ plans? Posted Jul 30, 2008 0:38 UTC (Wed) by oak (guest, #2786) [Link] > The article mentioned cruft, and it's a natural assumption that there's likely to be speed gains in ditching it. How much -- who knows? Anything performance related should be backed up with test-case(s), numbers and conclusions based on those numbers, everything else is bound to be dead wrong. > Honestly, the only speed impact I really notice from GTK+ is when firefox is rendering a particularly complex web page in a backgrounded tab, bringing the current tab essentially to a halt. I don't think this has anything to do with Gtk. Firefox doesn't use Gtk to draw www-page content (for obvious reasons, Gtk widgets are quite different from www-form widgets) and if it's in background tab, there isn't even anything to draw. I think it's more to do with JavaScript & Flash content (Flash doesn't use Gtk either), CSS and complex page layout / layering. Firefox has all tabs in same process (to save memory I assume) and AFAIK doesn't really thread its work that much.
|
|
||||||||||||