ensonic at hora-obscura.de
Thu May 24 08:58:02 UTC 2007
first congrats! Its an addictive toy already.
Quoting William Weston <weston at sysex.net>:
> 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?
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.
More information about the Linux-audio-dev