Re: GTK+ (Was: Evolution 2.0 and GNOME 2.6)



Hey

Thats just what miguel said. A little primer in UI programming is required.
Basically you have to tell each Widget to "show" itself. So say I have 
a window, with a button in it. Ideally I

1) Create the window
2) Create the button
3) Put button in window.
4) Show the button (**important)
5) Show the window.

Now if the programmer changes steps 4&5, you get that "feeling" of slowness.

HTH
Archit Baweja

"Eugenia Loli-Queru" <eloli hotmail com> writes:

> Because some people might wanna call me crazy over this, and I know I am
> not, I asked my husband (graphics engineer) to have a look at the "speed"
> issue for me and give me his insight. As I said on my previous email, it's a
> "feeling of unresponsiveness", more than anything else.
> 
> So, after showing him on my screen (please note I don't have gnome
> installation issues, I get the same feel of gtk on many machines with
> different OSes and gfx drivers even) what I consider "slow" and
> "unresponsive", he came to the conclusion that gtk's windows don't entirely
> construct themselves as fast as QT's do (our comparison was testing a number
> of different gnome and kde apps). It seems that the GTK way of displaying a
> new window or menu is to first render on screen the background view and then
> load on top of it its widgets. Other toolkits prefer to construct entirely
> the window and then show it on screen, but that's not to say that gtk's way
> is not good. It is just that I can visibly see the lag between the window
> construction and the population of widgets for a tenth of a second and that
> shouldn't happen IMHO. I think that's what gives me that *feeling* of
> slowness and unresponsiveness (a good example is when loading the
> /Preferences/File_Management panel or right clicking on kedit and gedit, I
> can see the window coming up and then the widgets coming up a short while
> after). These lag times are measured on the tenths of the second, granted,
> but it is still visible and it just bothers me (even if under the hood gtk
> might be faster than anything else out there, what matters sometimes to
> plain users is the "impression" they get from the way things  are rendered
> before their eyes).
> 
> Another thing that might be the culprit is some extra flickering that might
> be going on or might be the font handling, I don't know. Or, I might be just
> picky... but the overall impression on responsiveness gtk apps give me today
> on the widget/window level are not as high as kde's or XP's and I would
> sincerely like to see some improvements on this issue.
> 
> Rgds,
> Eugenia
> 
> 
> ----- Original Message ----- 
> From: "Owen Taylor" <otaylor redhat com>
> To: "Eugenia Loli-Queru" <eloli hotmail com>
> Cc: "Bastien Nocera" <hadess hadess net>; <desktop-devel-list gnome org>
> Sent: Saturday, January 31, 2004 2:07 PM
> Subject: Re: GTK+ (Was: Evolution 2.0 and GNOME 2.6)
> 
> 
> > On Sat, 2004-01-31 at 13:04, Eugenia Loli-Queru wrote:
> >
> > > I find GTK+ slower than Qt, yes, and also the overall "speed experience"
> is
> > > much worse than OSX's and XP's (especially the 2.x series). I have
> talked
> > > about this in the past but all we get from Owen in the bugzilla is "show
> me
> > > benchmarks" and "prove it with some code", which obviously doesn't help
> > > normal users (non-programmers) to explain the slowness.
> >
> > I'm wondering how that could possibly be a fair summary of:
> >
> >  http://bugzilla.gnome.org/show_bug.cgi?id=113040
> >
> > which is the bug in bugzilla. Yes, we haven't had the opportunity
> > yet to implement that optimization, but I don't even see any
> > mention of benchmarks in that bug. (Other places I've certainly mention
> > how important benchmarks are to doing performance work, but...)
> >
> > Regards,
> > Owen
> >
> >
> >
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list



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