Re: Why gtk+ application are so slow


Victor Nazarov <vir comtv ru> writes:

> I'm using Debian every day... And I've been trying to find why I
> prefer MS Widows GUI over Gnome. Now I've undesrtood. It's
> responsiveness. So I know that gtk+ is superior over Win32 becouse of
> it's portabillity and the most important is the ease of programming
> with it. But Gnome and GTK applications are considerably slower than
> Win32 applications. The time betwean the execution of application and
> the creation of the application's main window is very long... So I'd
> like to hear some opinions why is it so? I don't like to buy new,
> /modern/ computer, I want Gnome to work as fast as Windows 2000
> does...

Can you give some numbers please? I don't see any noticeable delay
when starting a GTK+ application. So I suspect that something is wrong
with your setup. There are several things that could be wrong. Your
font cache could be missing or broken, you might have an extended
input device configured which isn't available (this causes a long
timeout due to a bug in X11).

> Here is my opinion: I think the main problem is that gtk prefer
> run-time over compile time... So programmer binds callbacks on
> signals at run time... In win32 the compiler does it when compils
> WinProc functions switch statement... There are many other such
> examples. But I like gtk API and I don't whant to use clumsy Win32
> API. IMHO it's not a good idea to separate application code from the
> description of user interface (separated XML file for example). So I
> suggest to write a preprocessor for the gtk interface, something
> like yacc... So different statements of the preprocessed language
> will generate an array that will represents a whole window with all
> the widgets properly initialized, only some small subset of data,
> depending on the execution environment will be initialized at
> run-time. The task of the main function will only initialize minimum
> fields of array representing the window, point some gtk function to
> this array and run gtk_main... What do you think about this
> proposal?

I don't believe that this would gain any significant (noticeable)
improvement. But I am willing to change my mind if you can come up
with some serious profiling data for realworld applications that shows
that GObject signal marshalling is a major bottleneck.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]