Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
> For non-local servers without Render, Cairo will allow us to eliminate > the round-trips... a huge win. "Show me the money!" Back in the real world, new code goes in and someone files a performance bug. Then you, Owen, seem to take that as a personal insult and close it as NOTABUG or WONTFIX. Exhibit 1: bug 94718. A clear, to-the-point bug report that something (namely greying of toolbars) had gotten so much slower that it was a problem. It still is. Exhibit 2: bug 123538. Pango/GtkTreeview gets very slow with lots of data, a situation that "less" handled well a decade or two ago. I routinely use "less" on files larger than 1GB or with lines that are thousands of characters wide. While you didn't actually close this bug (we kept it under "Gnumeric") you seem to think I am outside what you designed for, hence my "Hello World" poke. Exhibit 3: bug 104683. General Pango performance with a patch that at the time cut 70% of cpu usage for the all-ASCII case (such as numbers) that Gnumeric uses heavily. You NOTABUG'd it *twice* (and "futured" it once) as evidently Pango's performance cannot possibly be problematic. I am somehow reminded of the word "attitude" reading these old, but still-open, bug reports. > Rendering speed is 90% an X server issue. I would normally define rendering speed as a measure of how fast you get your pixels on the screen. With that definition in mind, look at bugs 94718 and 104683 above and see that getting pixels on the screen got much slower with constant X server. The toolkit is much, much more than 10%. > We love you too, Morten. I am all cuddly. (Think Jack-Jack from a certain, recent animated movie.) M. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Owen, the problem with gtk+/cairo in a stable setting is that it has only seen testing and been designed for "hello world". You need to consider something bigger! Try putting 600-1000 pango layouts on the screen at once. GTK+ 2.6 is already not very snappy with that. Then make sure your X server is not local so you get to suffer the roundtrips also. I would like to hear from you that this has been considered and perhaps even tested. We still have not gotten anywhere near the screen update speed we had in the 1.2 days. Wearing my application developer hat, I would say that using GTK+ 2.8 for the next Gnome is crazy. It isn't right to enlist the unsuspecting users as guinea pigs just because you are having trouble getting people to test. The Cairo integration was done prematurely and now we suffer. Glib 2.8, on the other hand, fine. That's not a revolution. It might as well get renamed back to 2.6.whatever. And btw., we still are not near a state where the file chooser is acceptable. The "save-as" mode really stinks while the "open" mode is only marginally acceptable. See http://blogs.gnome.org/view/mortenw/2005/05/25/1 for example. Morten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
> - The benefit of having cool new rendering stuff in GNOME 2.12 Being cool never got any work done. > - The benefit of getting all this stuff tested early (i.e. before > GTK+ 2.8 is released, rather than after) We are talking a serious amount of new code that I have not tested, let alone run through Purify. Here's a prediction: it is not going to be pretty. > - The extra incentive for people to help with getting the rendering > stuff optimized I read that as "performance stinks unbelievably, but don't worry -- if we bother enough people surely someone will send us a hacky patch". The resident grouch's summary: there are NO BENEFITS that helps any user get any work done. There's a lot of fluff, though. Morten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
