Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:33 -0400, Owen Taylor wrote: On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote: Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? The way glitz integrates in is on the server side: GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL This will give the same basic performance benefits as having Cairo use glitz directly, but with many less complications. Currently, we don't foresee having GTK+ render via glitz as a very interesting way to go for the desktop. Note that the performance slowdowns people have been seeing for GtkTextView likely have not much to do with rendering and everything to do with text measurement. You'll have to excude me for not having followed much cairo/X work for a while, but does that ' --- RENDER ---' imply that cairo is rendering lots of traps using the RENDER extension? Thanks, Rob Taylor ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? Regards, Jeroen On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. The data: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: With the Mist theme, you are testing mixed Cairo and GDK rendering. Right now, that could conceivably hide some performance problems with Cairo. In the future, there are some performance optimizations that will be disabled when you are mixing Cairo and GDK rendering. The GTK+ builtin theme probably gives more of an accurate feel for GTK+/Cairo performance. What the appropriate theme to test is does depend on what we will be shipping for GNOME-2.10 as the default, of course. Which is likely not the GTK+ builtin theme. GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 Without studying what these benchmarks are actually doing, I'd consider them pretty encouraging ... some operations got faster, and what got slower is something we have in our sights already ... cairo_scaled_font_glyph_extents(). (GtkTextView performance is text measuring performance.) There is an obvious big-hammer approach that would allow us to get rid of that ... to put a cache in front of it so that we avoid calling into Cairo entirely, but I'd like to see what we can do inside of Cairo first. Regards, Owen BodyID:12373415.2.n.logpart (stored separately) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:21 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) I didn't know you could even use glitz with gtk+ HEAD? I asked owen, and he didn't think it worked atm. How did you run this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a suicidal drug-addicted ex-con fleeing from a secret government programme. She's a sarcastic insomniac mechanic trying to make a difference in a man's world. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Total time: 253.31 565.94 647.60 The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote: Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? The way glitz integrates in is on the server side: GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL This will give the same basic performance benefits as having Cairo use glitz directly, but with many less complications. Currently, we don't foresee having GTK+ render via glitz as a very interesting way to go for the desktop. Note that the performance slowdowns people have been seeing for GtkTextView likely have not much to do with rendering and everything to do with text measurement. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:47 -0400, Luis Villa wrote: On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Total time: 253.31 565.94 647.60 The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) I suspect that it's just difficulties in the benchmark ... especially with GtkTextView, things can happen a little differently each time you run it ... a different balance between repainting the screen and updating the text. Everything other than GtkTextView looked the same up to noise, but the GtkTextView numbers dominate the total. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 --- Total time: 253.31 565.94 I should have mentioned that this was with N=1000; jkh, I'm assuming you did the default n=100? Here are my numbers. The tendency is the same. I'm comparing the head of the 2.6 branch in cvs with HEAD. Both locally compiled with the same jhbuild setup. Default theme. Gtk branch 2.6 HEAD time time GtkEntry 0.04 0.07 GtkComboBox 1.11 1.51 GtkComboBoxEntry 0.99 1.17 GtkSpinButton0.07 0.11 GtkProgressBar 0.04 0.09 GtkToggleButton 0.21 0.41 GtkCheckButton 0.34 0.44 GtkRadioButton 0.41 0.65 GtkTextView - Add text 1.62 2.82 GtkTextView - Scroll 0.34 1.39 GtkDrawingArea - Lines 0.54 0.49 GtkDrawingArea - Circles 1.22 1.08 GtkDrawingArea - Text3.98 5.05 GtkDrawingArea - Pixbufs 1.23 1.00 --- --- Total time: 12.16 16.27 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. The data: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: With the Mist theme, you are testing mixed Cairo and GDK rendering. Right now, that could conceivably hide some performance problems with Cairo. In the future, there are some performance optimizations that will be disabled when you are mixing Cairo and GDK rendering. The GTK+ builtin theme probably gives more of an accurate feel for GTK+/Cairo performance. What the appropriate theme to test is does depend on what we will be shipping for GNOME-2.10 as the default, of course. Which is likely not the GTK+ builtin theme. GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 Without studying what these benchmarks are actually doing, I'd consider them pretty encouraging ... some operations got faster, and what got slower is something we have in our sights already ... cairo_scaled_font_glyph_extents(). (GtkTextView performance is text measuring performance.) There is an obvious big-hammer approach that would allow us to get rid of that ... to put a cache in front of it so that we avoid calling into Cairo entirely, but I'd like to see what we can do inside of Cairo first. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
