24 May
2007
24 May
'07
6:58 a.m.
Hi,
first congrats! Its an addictive toy already.
Quoting William Weston <weston(a)sysex.net>et>:
<snip>
If you use a compositing window manager such a compose, you'll have a
lot less expose events, as the window manager keeps a copy of the
window-content for composition. Some gtk-hackers also made experiemnts
with offscreen-bitmaps for widgets, but (I belive) it has not been
merged into gtk+ yet.
After much experimentation, I came to find that the
file menu
slowness was actually caused by the use of GTK's stock items, and no
amount of show/hide/realize calls could get the stock items to do
all of their initialization before the first time they're displayed.
So now that I've put my foot in my mouth, let me rephrase that
question: Any GTK hackers out there have any tricks for making sure
a that menus using stock items get fully initialized so that there
is no extra delay the first time they are accessed?
I would ask that on
gtk-app-devel list.
also, does this problem occur
when switching tabs to the oscillators page? the widgets are
realised on demand and there are a tonne of them on that page.
i would have expected much more of an impact from that.
I currently have menus without stock items and prebuilt file dialogs
in my codebase, and I can't get the GUI to cause any JACK xruns
anymore. I'll have to admit, redrawing all those widgets on demand
every time they reappear into view still makes it a bit sluggish.
Is there a way to make GTK cache the visual state of widgets (or
even whole windows) so that every widget on the page doesn't need to
be asked how to redraw itself from scratch every time it pops of of
view for whatever reason?
regards,
--ww
Ciao
Stefan