Hello Javier,
On 10 November 2011, Javier Jardón wrote:
Could you run the test again against the current stable GTK+
version? (GTK+ 3.2) Some optimization work has been done in that
release.
OK. As I can't test it on the original machine anymore, I'm going to
show the results on my current
On 23 July 2011 21:30, Jakub Misak jmi...@centrum.cz wrote:
Is GTK+ 3.x 2x slower than GTK+ 2.x?
Hello,
Hello Jakub,
So I made a (very) simple and stupid benchmark that tests a couple of
basic things in a loop, to see how the two GTK+ versions compare.
If you're interested, you can
On 10/17/2011 07:12 PM, David Nečas wrote:
On Mon, Oct 17, 2011 at 06:12:37PM +0200, Oscar Lazzarino wrote:
On 10/17/2011 11:51 AM, jcup...@gmail.com wrote:
On 17 October 2011 10:23, Clemens Eissererlinuxhi...@gmail.com wrote:
I was shocked by the bad performance of the tree list view from
Oscar Lazzarino oscar.lazzar...@i-m3d.com writes:
So appending n rows costs n*log(n), instead of n. Could be worse, but
could also be better, considering that the g_sequence has a
g_sequence_append method...
g_sequence_append() is Theta(n*log(n)) too.
Also, GSequence is not actually a splay
Hi,
I was shocked by the bad performance of the tree list view from the
beginning, so much that i'm now back to FOX toolkit.
Yes, the tree list few is probably one of the worst performing pieces
of code in GTK+.
When resizing Eclipse's main window with all its complex UI and
editors , the
On 17 October 2011 10:23, Clemens Eisserer linuxhi...@gmail.com wrote:
I was shocked by the bad performance of the tree list view from the
beginning, so much that i'm now back to FOX toolkit.
Yes, the tree list few is probably one of the worst performing pieces
of code in GTK+.
I wonder if
Hi,
Rhythmbox, for example, displays many thousands of lines of
information in a treeview and dragging the divider to make the widget
resize is fast and smooth. Resizing the whole window is slower since
that has to do a lot of WM magic. But the widget alone certainly seems
quick on my modest
On 10/17/2011 11:51 AM, jcup...@gmail.com wrote:
On 17 October 2011 10:23, Clemens Eissererlinuxhi...@gmail.com wrote:
I was shocked by the bad performance of the tree list view from the
beginning, so much that i'm now back to FOX toolkit.
Yes, the tree list few is probably one of the worst
On Mon, Oct 17, 2011 at 06:12:37PM +0200, Oscar Lazzarino wrote:
On 10/17/2011 11:51 AM, jcup...@gmail.com wrote:
On 17 October 2011 10:23, Clemens Eissererlinuxhi...@gmail.com wrote:
I was shocked by the bad performance of the tree list view from the
beginning, so much that i'm now back to
arround optimizing code for fun,
whereas paid devs are usually busy implementing feature requests and
repairing behaviour/crash/blocker-bugs.
- Clemens
2011/7/23 Jakub Misak jmi...@centrum.cz:
Is GTK+ 3.x 2x slower than GTK+ 2.x?
Hello,
When I upgraded to GTK+ 3.0, the first thing
2011/10/12 Clemens Eisserer linuxhi...@gmail.com:
I found the same slowdown during the GTK-1.2 - GTK-2 transition, and
it hasn't become a lot faster during the 2.x releases - moore's law
took care of it. I expect the same to happen with GTK3 sooner or later
(wether I like it or not, is a
- Original Message -
From: Jakub Misak jmi...@centrum.cz
To: gtk-list gtk-list@gnome.org
Cc:
Sent: Wednesday, October 12, 2011 8:49 PM
Subject: Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?
[snip]
GTK+ 2.24 was already markedly
slower than Qt 4.7, and now that GTK+ 3.0 is even 2
- Original Message -
From: Sergei Steshenko sergst...@yahoo.com
To: Jakub Misak jmi...@centrum.cz; gtk-list gtk-list@gnome.org
Cc:
Sent: Wednesday, October 12, 2011 9:18 PM
Subject: Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?
- Original Message -
From: Jakub
Hello Jakub,
Thursday, October 13, 2011, 1:49:44 AM, you wrote:
JM does not seem to be justifiable here. GTK+ 2.24 was already markedly
JM slower than Qt 4.7, and now that GTK+ 3.0 is even 2-3 times slower
JM than GTK+ 2.24, it is really becoming a competitive disadvantage.
The problem is that
On Sun, Jul 24, 2011 at 11:44:29AM -0700, Sergei Steshenko wrote:
All of these are relevant questions.
But a bug report is a responsibility of some _paid_ developers, so their
managers will be nagging the developers to resolve the issues.
/rant on/
I thing the real issue here is probably
On 07/23/2011 08:30 PM, Sergei Steshenko wrote:
File a bug.
Filing such a broad bug report isn't likely to be that helpful. The OP
was kind enough to provide some pseudo-benchmarking code. Perhaps with
the help of the mailing list community the actual causes of the
slowdowns can be determined,
--- On Sun, 7/24/11, Michael Torrie torr...@gmail.com wrote:
From: Michael Torrie torr...@gmail.com
Subject: Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?
To: gtk-list@gnome.org
Date: Sunday, July 24, 2011, 9:26 AM
On 07/23/2011 08:30 PM, Sergei
Steshenko wrote:
File a bug.
Filing
I think Gtk3 uses Cairo for all of its drawing, which
may account for at least some of the slowdown. Cairo
does a lot of sophisticated things, and that comes at
a cost.
--
Greg
___
gtk-list mailing list
gtk-list@gnome.org
Is GTK+ 3.x 2x slower than GTK+ 2.x?
Hello,
When I upgraded to GTK+ 3.0, the first thing that struck me was how
sluggish it was compared to 2.24. The same dialogs in the same
application appear immediately on the screen in the 2x version, while
it takes time to paint them on the screen
--- On Sat, 7/23/11, Jakub Misak jmi...@centrum.cz wrote:
From: Jakub Misak jmi...@centrum.cz
Subject: Is GTK+ 3.x 2x slower than GTK+ 2.x?
To: gtk-list@gnome.org
Date: Saturday, July 23, 2011, 12:30 PM
Is GTK+ 3.x 2x slower than GTK+ 2.x?
Hello,
When I upgraded to GTK+ 3.0
20 matches
Mail list logo
