| |||||||||||||
|
| |||||||||||||
any detailed info on GTK+ plans?any detailed info on GTK+ plans?Posted Jul 29, 2008 18:38 UTC (Tue) by oak (guest, #2786)In reply to: any detailed info on GTK+ plans? by mmarsh Parent article: GNOME 3.0 worries
> My impression was that the "gain" in the ABI breakage would be a smaller, more-responsive GTK+ due to the expulsion of cruft. That can be pretty significant for a lot of people, say those of us limping along on six-year-old laptops. Do you have any link that would list this "cruft" and any *numbers* on what expelling it would gain? I doubt the speedup would be anything user visible (10% sounds pretty optimistic and something like that isn't really user visible).
(Log in to post comments)
any detailed info on GTK+ plans? Posted Jul 29, 2008 18:59 UTC (Tue) by brouhaha (subscriber, #1698) [Link] I too doubt that there would be any speedup. I think the issue is more a matter of getting rid of deprecated interfaces and fields so that new code doesn't have to support them. There's too much internal detail exposed, which makes it difficult to add new features while maintaining full compatibility. That's why they want to make the structures opaque and use setter/getter functions.
any detailed info on GTK+ plans? Posted Jul 29, 2008 23:14 UTC (Tue) by mmarsh (subscriber, #17029) [Link] 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.
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.
|
|
||||||||||||