[LAD] PHASEX-0.10.2

William Weston weston at sysex.net
Thu May 24 07:56:19 UTC 2007

On Wed, 23 May 2007, pete shorthose wrote:

> On Tue, 2007-05-22 at 16:21 -0700, William Weston wrote:
> > I'll be looking into the patch loading issue next.  From what I can
> > tell, the first access of the File menu (either by hitting it
> > directly or accessing an item through a keyboard acceleration)  
> > causes enough of a CPU hit to disrupt other threads.  This is the
> > only menu that currently uses the GTK stock items and keyboard
> > accelerations.  Any GTK hackers out there have any tricks for making 
> > sure a GtkAccelGroup has fully initialized itself?
> do you have a specific reason to lay blame on the accel group?
> more than say, the open dialog?

This reasoning was based on the fact that only the file menu uses
accelerators, and only the file menu experienced the delay (and only
on the first access), whether accessed by clicking with the mouse or
using a keyboard accelerator.  The first access of the file menu 
would cause JACK xruns about half the time, while opening a file 
dialog after the file menu has already been accesed would not cause 

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?

> 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?


More information about the Linux-audio-dev mailing list