On Fri, 07 Jul 2006 07:54:33 +0200, Clemens Eisserer wrote:
>> Just to be clear here: I am a reasonably proficient user. I'm not an
>> expert. I am just a user with a working knowledge of compiling stuff
>> up. I
> So no code from you ... sad :-(
As I've said all along, I'm not a coder. I'm just
On Thu, 06 Jul 2006 17:49:31 -0600, Mark Leisher wrote:
> Roo wrote:
>> On Thu, 06 Jul 2006 16:52:40 -0600, Mark Leisher wrote:
>>
>>> Roo wrote:
%configure --with-xinput=xfree --disable-gtk-doc --without-pic
>>> Another configure annoyance. The command line parameter to disable
>>> sha
Hi again,
> Just to be clear here: I am a reasonably proficient user. I'm not an
> expert. I am just a user with a working knowledge of compiling stuff up. I
So no code from you ... sad :-(
> to be given some straightforward instructions on what to do and where to
> find the tools necessary to co
Roo wrote:
> On Thu, 06 Jul 2006 16:52:40 -0600, Mark Leisher wrote:
>
>> Roo wrote:
>>> %configure --with-xinput=xfree --disable-gtk-doc --without-pic
>>>
>> Another configure annoyance. The command line parameter to disable
>> shared code is typically --disable-shared. I don't recall having seen
On Thu, 06 Jul 2006 16:52:40 -0600, Mark Leisher wrote:
> Roo wrote:
>> %configure --with-xinput=xfree --disable-gtk-doc --without-pic
>>
> Another configure annoyance. The command line parameter to disable
> shared code is typically --disable-shared. I don't recall having seen
> --without-pic be
Roo wrote:
> On Thu, 06 Jul 2006 22:52:34 +0100, Roo wrote:
>
>> On Thu, 06 Jul 2006 22:41:03 +0100, Roo wrote:
>>
>>> Ok, well... I'll try it out. I have "gtk2-2.8.19-2.src.rpm" downloaded
>>> and I've installed it locally. I've taken a look at the spec file, but
>>> I don't know how to alter it
On Thu, 06 Jul 2006 17:15:38 -0500, Michael Ekstrand wrote:
> You're comparing it with itself. If the profiler reports that GTK is
> consistently spending 75% of its time in Cairo, then yeah, Cairo (or at
> least the manner in which GTK uses Cairo) is a problem. But if it
> spends 5% of its time
On Thu, 06 Jul 2006 17:15:38 -0500, Michael Ekstrand wrote:
> Or maybe they just don't want to maintain two different sets of drawing
> code for every widget.
Or maybe they could have not ripped out code in a supposed "stable" code
base?
> Whatever the full reasoning, I'm convinced the GTK devel
On Thu, 06 Jul 2006 22:52:34 +0100, Roo wrote:
> On Thu, 06 Jul 2006 22:41:03 +0100, Roo wrote:
>
>> Ok, well... I'll try it out. I have "gtk2-2.8.19-2.src.rpm" downloaded
>> and I've installed it locally. I've taken a look at the spec file, but
>> I don't know how to alter it to work without -fP
On Jul 6, 2006, at 3:41 PM, Roo wrote:
So basically: there are more variables than just GTK.
>>>
>>> Ok, so presumably there's a way to take gtk2-2.8.19-2.src.rpm (the
>>> currently installed GTK2 on my FC5 system) and recompile it (or is
>>> there an env var?) telling it not to use Cairo so I
On Thu, 06 Jul 2006 22:41:03 +0100, Roo wrote:
> Ok, well... I'll try it out. I have "gtk2-2.8.19-2.src.rpm" downloaded
> and I've installed it locally. I've taken a look at the spec file, but I
> don't know how to alter it to work without -fPIC. If you can tell me
> how, then I'll rebuild it, ins
On Thu, 06 Jul 2006 17:09:11 -0400, Valdis.Kletnieks wrote:
> On Thu, 06 Jul 2006 22:59:35 +0200, Clemens Eisserer said:
>> Just a side note: GTK-2.9.4 built with "-O2 -g -fPIC" is a lot slower
>> than the stuff shipped with OpenSuSE (I guess 2.8.6+). maybe the
>> debugging symbols cause cache mis
On Thu, 06 Jul 2006 22:59:35 +0200, Clemens Eisserer wrote:
> Just a side note: GTK-2.9.4 built with "-O2 -g -fPIC" is a lot slower
> than the stuff shipped with OpenSuSE (I guess 2.8.6+). maybe the
> debugging symbols cause cache misses ... I don't know but its about
> 25-75% slower.
What option
On Thu, 06 Jul 2006 22:59:35 +0200, Clemens Eisserer said:
> Just a side note: GTK-2.9.4 built with "-O2 -g -fPIC" is a lot slower
> than the stuff shipped with OpenSuSE (I guess 2.8.6+). maybe the
> debugging symbols cause cache misses ... I don't know but its about
> 25-75% slower.
The debugging
Hi Roo,
Just a side note: GTK-2.9.4 built with "-O2 -g -fPIC" is a lot slower
than the stuff shipped with OpenSuSE (I guess 2.8.6+). maybe the
debugging symbols cause cache misses ... I don't know but its about
25-75% slower.
> Right... so the GTK developers left normal users without the ability
On Thu, 06 Jul 2006 21:38:04 +0100, John Cupitt wrote:
> On 7/6/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote:
>> > I'm seeing these issues, and I'm fed up of them not being fixed. I'd
>> > like
>> > to know what tools the GTK developers use for measuring performance
>> > changes, and how I can c
On Thu, 06 Jul 2006 14:11:18 -0500, Michael Ekstrand wrote:
> On Jul 6, 2006, at 1:28 PM, Roo wrote:
>> On Thu, 06 Jul 2006 08:21:56 -0500, Michael Ekstrand wrote:
>>> Part of the problem/reason: for some reason, it seems to work (or at
>>> least give acceptable results) for many of us.
>>
>> No d
On 7/6/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote:
> > I'm seeing these issues, and I'm fed up of them not being fixed. I'd
> > like
> > to know what tools the GTK developers use for measuring performance
> > changes, and how I can cut out Cairo in order to get a grip on exactly
> > what is goi
On Jul 6, 2006, at 1:28 PM, Roo wrote:
> On Thu, 06 Jul 2006 08:21:56 -0500, Michael Ekstrand wrote:
>> Part of the problem/reason: for some reason, it seems to work (or at
>> least give acceptable results) for many of us.
>
> No doubt, when you throw enough hardware at problems it does tend to
>
On Thu, 06 Jul 2006 08:21:56 -0500, Michael Ekstrand wrote:
> Part of the problem/reason: for some reason, it seems to work (or at
> least give acceptable results) for many of us.
No doubt, when you throw enough hardware at problems it does tend to hide
them.
> So basically: there are more varia
Clemens Eisserer wrote:
>> Welcome to the wonderful world of GTK... where performance keeps going
>> down with every new version.
> Well that was also my impression and nobody really cared about my
> complaints (e.g. one complained about gtk/windows performance, he was
> flamed, I gave an example -
On Jul 6, 2006, at 6:43 AM, Roo wrote:
> Welcome to the wonderful world of GTK... where performance keeps going
> down with every new version. My experience: GTK has always been a slug
> compared to other toolkits, but when I upgraded from FC4 to FC5, it
> included a version of GTK that was built w
> Welcome to the wonderful world of GTK... where performance keeps going
> down with every new version.
Well that was also my impression and nobody really cared about my
complaints (e.g. one complained about gtk/windows performance, he was
flamed, I gave an example -> thread was dead, nobody answer
On Tue, 20 Jun 2006 15:26:51 +0200, Clemens Eisserer wrote:
> I just don't get it why I need a 3ghz PC to not see repaint lags or 5fps
> layout updates.
> These things worked years ago ten times better than now (and no, this
> are not themes. GTK-1/QT-2 were themed too with tons of pixmaps). What
Hi again,
Thanks a lot for all the hints about gdk, I know found the
source-parts which I looked for and thanks to the paper I even
understand what they are doing :-)
I thought about some techniques about implementing buffer release
heuristics, however they destroy the benefit to smoe degree and
On Mon, Jun 26, 2006 at 08:14:14PM +0200, Clemens Eisserer wrote:
> As far as I understood from the gtk-tutorial there are some widgets
> which are windows themself ... which is a bit confusing for me.
> I tried to find the entrance point where X tells gtk windows to
> expose,
X tells Gtk+ nothing
Hello John,
Thanks a lot for beeing that patient and constructive, its really motivating!
I know I am not the dream-guy to start working on this but hey what
can GTK loose ;)
> I think the artifacts are because, with double-buffering turned off,
> expose events do not get an automatic clear-to-ba
On 6/25/06, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> When I maximize the window and resize the panes I get very slow
> resizing, however when setting all involved widgets unbuffered
> resizing is fast (but painting is done with artifacts).
I think the artifacts are because, with double-buffer
Hello John,
Thanks a lot for answering.
I created a sample program which contains two buttons in a
(horizontally) paned window.
When I maximize the window and resize the panes I get very slow
resizing, however when setting all involved widgets unbuffered
resizing is fast (but painting is done with
On 6/24/06, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> [quote]So I guess I didn't reproduce your problem. In my case, the
> reason so much time is spent in software solid fills and copies is
> that GTK seems to create and destroy pixmaps at a fantastic rate. In
> fact, it creates and destroys a
Hello again,
I did some further testing and found that even the gtk-demo part
"paned widgets" show such low performance if the panes are as large as
the whole screen.
I further talked to an nvidia driver developer which also analysed the
situation and got a profile very similar to mine.
This is w
Hello again,
Thanks a lot for sending your results of the 6200.
It seems that (on my system) 35% of total cpu time are spent in
software rendering related stuff (I guess _nv000805X is some kind of
vram readback or upload function).
When running gftp with the open-source "nv" driver performance fe
Hello Paul,
> GTK2, for some unknown reason, abandoned that
> approach and instead keeps issuing resize events as the mouse moves. its
> completely and totally braindead as the default behaviour, although i
> would concede that there are situations where it would be nice to have
> this available.
On Tue, 2006-06-20 at 19:43 -0400, [EMAIL PROTECTED] wrote:
> Was this your Eclipse test, or gftp? What I'm seeing on the 'wiggle the
> dividing bar on gftp till it saturates the CPU' is this: (and yes, it's a
> generic GTK issue, not gftp, unless the 3 other apps I tested did the same
> wrong thi
On 6/21/06, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> You were right, novell installed by default a gtk-qt-engine package,
> that was also the reason why I was not able to get rid of "this one
> and only theme". Now I am using the default theme and its _way_
> better, I see about twice as much
On 6/21/06, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> You were right, novell installed by default a gtk-qt-engine package,
> that was also the reason why I was not able to get rid of "this one
> and only theme". Now I am using the default theme and its _way_
> better, I see about twice as much
Hello Valdis,
Thanks again for taking all the time :-)
You were right, novell installed by default a gtk-qt-engine package,
that was also the reason why I was not able to get rid of "this one
and only theme". Now I am using the default theme and its _way_
better, I see about twice as much refresh
Hello Nick,
> I don't know if this has any relevance now, but I experienced similar poor
> performance a while ago with a machine who's configuration was very
> similar to yours (Athlon 1000, Nvidia FX5200) and it seemed related to the
> Nvidia binary driver current at the time (a couple of years
On Tue, 20 Jun 2006, Clemens Eisserer wrote:
> Hi there,
>
> I recently updated to OpenSuSE 10.1 since some people suggested that
> Eclipse/GTK's performance is better with gtk 2.8.
> My machine is a Athlon 1000 with 512mb SDram and a GeForce FX5200 with
> latest NVidia binary drivers, renderacc
On Wed, 21 Jun 2006 00:41:31 +0200, Clemens Eisserer said:
> I did some oprofiling, however I don't have a vmlinz-file handy so its
> quite a bit useless:
> 5558 39.2930 no-vmlinux
Bummer. With a system time *that* high, I'm wondering if there's something
odd going on here... a vmlinux to h
Hi again,
> I'm suspecting you're addressing me with that comment. ;)
Well, maybe ;)
When I wrote the original post I was quite frustrated since I was
unhappy about GTKs performance since a long time (I used FC3 (2.4) and
FC4(2.6) and now OpenSuSE 10.1 (2.8), my laptop died (2.6ghz) and now
I've t
On 6/20/06, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> Thanks for the tip with the theme, the only theme I've installed is
> called "Raleigh".
I found the package:
http://www.novell.com/products/linuxpackages/suselinux/gtk-qt-engine.html
it is installed by default, so unless you've removed it
Clemens Eisserer wrote:
>
>> (1.6Ghz CPU, 768M of RAM, and an NVidia 440Go chipset), hardly a screamer
> Well but it should be enough to handle these simple tasks very fast.
> If QT can do it fast, GTK should be able too.
>
> I just wonder why QT performs that well (and many other toolkits I've
>
On Tue, 20 Jun 2006 22:21:16 +0200, Clemens Eisserer said:
> 1.) Not even one comment from a developer. Maybe there are not enough,
> maybe nobody cares, ore maybe they can't cope with critic? I don't
> know.
Maybe none of the developers are seeing your issue, and none of the usual
bleeding-edge
Hi again,
Maybe GTK is using X in a way it does not like?
> of 2 other 700x1000 windows, and the window manager is doing the moving window
> in translucent mode as well, that *will* spike the processor up to about 100%
> and only 8 or 10 redraws per second.
Well but then a composition manager is
On Tue, 20 Jun 2006 15:26:51 +0200, Clemens Eisserer said:
> Where does all the time go to? I've done some sysprof-profiling and
> its shows than pango is not the evil. Are maybe the repaint
> algorythmns not optimal, repainting too often too large areas/hidden
> components?
So where *does* the t
On 6/20/06, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> I recently updated to OpenSuSE 10.1 since some people suggested that
> Eclipse/GTK's performance is better with gtk 2.8.
> My machine is a Athlon 1000 with 512mb SDram and a GeForce FX5200 with
> latest NVidia binary drivers, renderaccel ena
Hi there,
I recently updated to OpenSuSE 10.1 since some people suggested that
Eclipse/GTK's performance is better with gtk 2.8.
My machine is a Athlon 1000 with 512mb SDram and a GeForce FX5200 with
latest NVidia binary drivers, renderaccel enabled.
GTK applications tend to be very unresponsive
On Fri, 2003-11-28 at 20:15 +0100, Lambert Schomaker wrote:
> Hi Iain and others,
>
> thanks for the support. In order to notice what
> the problem is, you may want to use eog immediately
> after using my prog, looking at the same .tif:
> eog scrolls like a snowboard on snot.
I didn't really noti
Hi Iain and others,
thanks for the support. In order to notice what
the problem is, you may want to use eog immediately
after using my prog, looking at the same .tif:
eog scrolls like a snowboard on snot.
Since in our application, the images will even
be bigger than the .tif example, and in color,
On Fri, 2003-11-28 at 11:09 +0100, Lambert Schomaker wrote:
> Hi GTK-ers,
>
> for those interested in my jerky scroll problem: here is
> the .tgz with the .tif file that shows it on my supposedly
> fast 3 GHz system.
>
> http://www.ai.rug.nl/~lambert/overslag/jerky-image-viewer.tgz
For what i
Not sure if this is your problem, but I had very helpful mails a few month ago from Owen and Sven when I asked about diagonal scrolling slowness. Here's the one from Soeren:
Soeren Sandmann wrote:
John Cupitt <[EMAIL PROTECTED]> writes:
One of the app's widgets is an image display window, and on
Hi GTK-ers,
for those interested in my jerky scroll problem: here is
the .tgz with the .tif file that shows it on my supposedly
fast 3 GHz system.
http://www.ai.rug.nl/~lambert/overslag/jerky-image-viewer.tgz
The binary is here:
> cd jerky-image-viewer/src/
> project2
Hi,
I am new to GTK+ so the question may be dumb.
We are buidling an image viewer / annotator using glade-2:
glade-2 1.1.3
libgtk-1.2.so.0.9.1
libgtk-x11-2.0.so.0.200.1
libpango-1.0.so.0.200.1
libpangoxft-1.0.so.0.200.1
libgcc_s-3.2.2-20030225.so.1
Hardware: 3 GHz/1 GB.
OS: Linux RH 9.
When using
54 matches
Mail list logo
