Re: REALITY CHECK: Resource usage of gnome

[<nuke bayside net>]

i would just like to enforce what the original poster of this thread said.
opaque moving/resizing gtk apps is noticeably slower than other toolkits
(Athena, Motif, Qt), and in gmc, it's ridiculous.

as i posted before, i'm not harping on anyone about it... i am
investigating fixing things up myself. the problem is that i don't know
where to start. if there's anyone who could point me in the right
direction, i'd really appreciate it.

for example: the buttons in testgtk. try opaque moving (without backing
store) a window over those. watch them all be erased and redrawn. to be
honest, i don't have any idea how a widget could know wether it needs a
full redraw or just the part that the window was moved over.

maybe someone with better knowledge of X widget drawing mechanics could
help out?

> > I have experienced these same things...resizing gmc is awful! And, for
> > some reason, if I start gmc moving windows (opaque) slows way down. I
> > haven't played around w/ gnome enough yet to see if it's slow at anything
> > else, but this is very noticeable. I know it's one of those things to be
> > fixed Very Soon Now (tm).
> 
> As I was answered on this list previously, the main problem is that all
> desktop icons are shaped pixmaps, and the Open Group's way for handling
> these is kludgy at best. So unless you have an X server that does something
> smarter with them, you have a problem.
> 
> Now I'm having a few doubts about this. I have fvwm2 compiled with shaped
> pixmaps and most of my icons for it are shaped, and I've never had any
> problems. But then again since fvwm2 is in charge of those *and* window
> operations it probably handles the whole thing rather smartly.
> 
> I haven't done any coding for X (yet, GNOME is my first target, but it'll
> have to wait until after my exams), but I still wonder why gmc is getting
> requests to redraw its icons even when there's no movement over them. I'm
> not sure this is an X issue. I'm in the dark here, but is gmc redrawing
> icons based on redraws of the root window instead of redraws for the icons
> themselves? Maybe we should look at fvwm2's handling of icon redraws and see
> if we can snitch some code from there. It seems to handle shaped windows
> flawlessly.
> 
> And it's not a matter of resources. I have a PMMX/200 with 32 megs of RAM
> (and about 100M of swap) and an accelerated server for my Viper V330. That
> should be blazing fast, and it is for anything other than gmc. I still think
> this is gmc's problem. Maybe the event monitoring loop for drag & drop
> events is badly optimized? Can the coders offer an insight?
 _        _  __     __             _ _                                  _
|        / |/ /_ __/ /_____         |       Nuke Skyjumper               |
|       /    / // /  '_/ -_)        |         "Master of the Farce"      |
|_     /_/|_/\_,_/_/\_\\__/        _|_           nuke@bayside.net       _|