Hi,
I am facing performance issues in GTK upon presenting a big amount of
tabular data. First I used GtkListbox for it's layout flexibility.
Handling more than 10,000 items gets inacceptable slow. Switching to
GtkTreeview I can handle some 300,000 items after applying a few
optimizations (column s
Hello,
I don’t know about GtkListBox, but when using GtkTree, are you detaching
your model from the treeview while you are doing mass operations on it?
I remember reading it in a tutorial years (decades?) ago that you should
do this.
Sorry, but i have no answers at hand for your other questions.
about this:
> is there any way to create callbacks from the javascript world using the
Webkit2Gtk webview?
I've created a JSON communication channel between GJS and the WebView
through title notifications:
https://gist.github.com/WebReflection/7ab0addec037508cc8380a9c37d285f2#gistcomment-2245132
On Mon, 2018-10-08 at 14:06 +0200, Andrea Giammarchi wrote:
> about this:
> > is there any way to create callbacks from the javascript world
> > using the
> Webkit2Gtk webview?
> I've created a JSON communication channel between GJS and the
> WebViewthrough title notifications:
> https://gist.githu
clock was I could not “double click” on anything.)
They felt that they may have a fix for this problem in SUSE 10.0. It may
be that the Athlon clock fix in SUSE 10.0 is what is hindering your GTK
performance. I really hope this isn’t your problem.
BTW – I have since returned to using my old 1.7
Why is GTK's performance so bad on Windows ?
Of all the gui tookits I use, it has the worse performance.
I am interested in GTK on Windows because I want to make cross-platform
applications.
Isn't there a new version on the horizon that will fix this ?
Or what can be done to tune the performance
l-time clock interrupt. (One side-effect of the
> warp speed system clock was I could not “double click” on anything.)
> They felt that they may have a fix for this problem in SUSE 10.0. It
> may be that the Athlon clock fix in SUSE 10.0 is what is hindering
> your GTK performance. I rea
be that the Athlon clock fix in SUSE 10.0 is what is hindering
> > your GTK performance. I really hope this isnât your problem.
>
> it sounds quite likely that you have been the victim of some slightly
> uninformed customer support. was this a dual core Athlon?
No, the "
Alex Nedelcu wrote:
> Why is GTK's performance so bad on Windows ?
> Of all the gui tookits I use, it has the worse performance.
>
> I am interested in GTK on Windows because I want to make cross-platform
> applications.
>
> Isn't there a new version on the horizon that will fix this ?
> Or what
Alex Nedelcu writes:
> Why is GTK's performance so bad on Windows ?
Because you haven't profiled it and contributed performance
improvements?
> Of all the gui tookits I use, it has the worse performance.
Well, d'oh, you should ask for your money back then!
--tml
He must have been adding sleeps in his code.
Tor Lillqvist schreef:
> Alex Nedelcu writes:
>
> > Why is GTK's performance so bad on Windows ?
>
> Because you haven't profiled it and contributed performance
> improvements?
>
> > Of all the gui tookits I use, it has the worse performance.
>
> Well
1.) Is this really nescessary?
This guy has performance problems on windows asking for help (well,
maybe a bit indirect) ... and this is what he gets.
Go to QT's bugzilla and search for performance bugs
2.) How could he profile it.
I asked two times for ways to find out which operations are d
Clemens Eisserer writes:
> 1.) Is this really nescessary?
> This guy has performance problems on windows asking for help (well,
> maybe a bit indirect) ... and this is what he gets.
I am sorry for being a but rude, but I found his mail more of an
accusation than a question.
> Go to QT's bugzi
First of all thanks a lot for doing that much work porting GTK to windows.
I can't count how many apps I've used myself on windows-pcs which were
able to run because of your work.
> If one would ask specific question like "I draw 10 line segments
> with separate gdk_draw_line() calls, and it's
I played a bit and found something which could be considered as "slow":
Open the configuration dialog of gimp and move another window on top of it.
This spikes cpu useage to 80-90% on an AMD Athlon XP 2000+, while you
can still see a ~4mm repaint lag.
I wonder wether this could also be caused bec
15 matches
Mail list logo
