Severe treeview performance regression (Gtk2 - gtk3)
Hi, Fedora16 comes with a gtk3 port of Audacious. After updating I immediatly noticed how slow the playlist scrolls (a quite ordinary TreeView with a few hundred lines), when scrolling using the scrollwheel GTK3 barely keeps up, which usually results in afterscrolling - on a Core2Duo with 2ghz / 4MB cache. GTK2's TreeView was not fast either (compared to e.g. Java's JTable), but it didn't feel disturbing. I hacked together a simple sample application which compiles under gtk2 as well as gtk3: http://93.83.133.214/gtklist.c Just maximize it (preferable on a large screen) and scroll with your wheel - the gtk3 version should feel a lot slower. Would be great if somebody could have a look at this regression. I didn't file a bug-report, because usually bugzilla reports fade away into legacy unnoticed. Thank you in advance, Clemens ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Thu, Oct 20, 2011 at 12:03:17PM +0200, Clemens Eisserer wrote: Hi, Fedora16 comes with a gtk3 port of Audacious. After updating I immediatly noticed how slow the playlist scrolls (a quite ordinary TreeView with a few hundred lines), when scrolling using the scrollwheel GTK3 barely keeps up, which usually results in afterscrolling - on a Core2Duo with 2ghz / 4MB cache. GTK2's TreeView was not fast either (compared to e.g. Java's JTable), but it didn't feel disturbing. I hacked together a simple sample application which compiles under gtk2 as well as gtk3: http://93.83.133.214/gtklist.c Just maximize it (preferable on a large screen) and scroll with your wheel - the gtk3 version should feel a lot slower. Would be great if somebody could have a look at this regression. I didn't file a bug-report, because usually bugzilla reports fade away into legacy unnoticed. Thank you in advance, Clemens Hi, I'm using gtk2 (2.22) and had (my own) small program which when I changed 2.20 - 2.22 became teribly slow. It uses GtkTreeView. The workaround was to switch off the sorting of the TreeView while adding a large number of items and set it when the list is filled. Then, the TreeView became very quick. Maybe this is connected also to the gtk3 problem? (Anyway, it is a bug... :-( ) P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote: I hacked together a simple sample application which compiles under gtk2 as well as gtk3: http://93.83.133.214/gtklist.c Just maximize it (preferable on a large screen) and scroll with your wheel - the gtk3 version should feel a lot slower. I have noticed that as well on GTK+ 3 a year ago or so, and I don't think this is specific to GtkTreeView. Back then I got the impression that some parts of the drawing synchronization (i.e. draw the moved area and the newly exposed area at the same time instead of first drawing the moved area and drawing the newly exposed area later) did not make it into the client-side-windows code. However, I was told that such problem should not exist with client side windows (I was not convinced though). regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Thu, 2011-10-20 at 18:15 +0200, Kristian Rietveld wrote: On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote: I hacked together a simple sample application which compiles under gtk2 as well as gtk3: http://93.83.133.214/gtklist.c Just maximize it (preferable on a large screen) and scroll with your wheel - the gtk3 version should feel a lot slower. I have noticed that as well on GTK+ 3 a year ago or so, and I don't think this is specific to GtkTreeView. Back then I got the impression that some parts of the drawing synchronization (i.e. draw the moved area and the newly exposed area at the same time instead of first drawing the moved area and drawing the newly exposed area later) did not make it into the client-side-windows code. However, I was told that such problem should not exist with client side windows (I was not convinced though). The csw code takes a lot of care to try to ensure this. However, the csw code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and a csw version of Gtk2. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
Hi, The csw code takes a lot of care to try to ensure this. However, the csw code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and a csw version of Gtk2. I wonder why the gtk3 version of the treeview is so much slower Scrolling such a basic widget on todays desktop processors shouldn't cause any troubles (I also developed a Swing JTable and a QT version, both scroll without any problems). Profiling with sysprof didn't reveal a single hotspot, its quite a flat profile with many lukewarm places. It seems, however, painting is not the problem (both cairo and X11 stuff doesn't show anywhere near top) Would be great if someone more experienced could have a look at the demo, probably there are some lower-level issues that cause performance regressions elsewhere too. Thanks, Clemens ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Thu, 20 Oct 2011, Clemens Eisserer wrote: The csw code takes a lot of care to try to ensure this. However, the csw code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and a csw version of Gtk2. I wonder why the gtk3 version of the treeview is so much slower Scrolling such a basic widget on todays desktop processors shouldn't cause any troubles (I also developed a Swing JTable and a QT version, both scroll without any problems). Profiling with sysprof didn't reveal a single hotspot, its quite a flat profile with many lukewarm places. It seems, however, painting is not the problem (both cairo and X11 stuff doesn't show anywhere near top) Would be great if someone more experienced could have a look at the demo, probably there are some lower-level issues that cause performance regressions elsewhere too. I compiled your gtklist.c using (a) gtk-2.24.7 and friends (latest stable stack) (b) gtk-3.2.1 and friends (again, all latest stable) I can't detect any difference in the scrolling performance in the two cases; it seems quite acceptable in both. This is on Linux 3.0.7, glibc 2.14, gcc 4.6.1, Core i5 2520M 2.50GHz, Lenovo Thinkpad with wheel-type scrolling via Trackpad. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
Hi Allin, (a) gtk-2.24.7 and friends (latest stable stack) (b) gtk-3.2.1 and friends (again, all latest stable) I can't detect any difference in the scrolling performance in the two cases; it seems quite acceptable in both. This is on Linux 3.0.7, glibc 2.14, gcc 4.6.1, Core i5 2520M 2.50GHz, Lenovo Thinkpad with wheel-type scrolling via Trackpad. Thanks for testing :) I am on Fedora-16 with gtk-3.2.0-1 using the gtk3's default theme I can easily produce several seconds of after-scrolling, however I have a large monitor (1920x1200). gtk2 is gtk2-2.24.6 with Mist theme. Both results are not good, even with gtk2 I can't just grab the slider and scroll without stuttering (which works with Java and QT), however with gtk3 its a lot slower. How much is hard to quantify without frameworks available to measure. Your CPU is about ~50% faster than mine - probably that's just enough to not let scroll-events queue up? Thanks, Clemens ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Thu, 20 Oct 2011, Clemens Eisserer wrote: Hi Allin, (a) gtk-2.24.7 and friends (latest stable stack) (b) gtk-3.2.1 and friends (again, all latest stable) I can't detect any difference in the scrolling performance in the two cases; it seems quite acceptable in both. This is on Linux 3.0.7, glibc 2.14, gcc 4.6.1, Core i5 2520M 2.50GHz, Lenovo Thinkpad with wheel-type scrolling via Trackpad. Thanks for testing :) I am on Fedora-16 with gtk-3.2.0-1 using the gtk3's default theme I can easily produce several seconds of after-scrolling, however I have a large monitor (1920x1200). gtk2 is gtk2-2.24.6 with Mist theme. Both results are not good, even with gtk2 I can't just grab the slider and scroll without stuttering (which works with Java and QT), however with gtk3 its a lot slower. How much is hard to quantify without frameworks available to measure. Your CPU is about ~50% faster than mine - probably that's just enough to not let scroll-events queue up? Possibly. Since you mention themes, I should say that with both gtk2 and gtk3 I'm using no theme, just the plain vanilla out-of-the-box gtk appearance (which looks much better in gtk2). I don't know how relevant this is to scrolling speed. Allin___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Severe treeview performance regression (Gtk2 - gtk3)
On Thu, Oct 20, 2011 at 09:45:10PM +0100, Lionel Landwerlin wrote: GtkList isn't based on treeview AFAIK Please look at the source code before making such remarks. Anyway, I was about to note that I observed the Gtk+3 version to be faster (both version from Fedora 15 packages). But then I realized that while Gtk+3 uses the default theme the Gtk+2 theme is Glider. After fixing that the subjective performance was pretty much the same. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
