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 xruns. 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? regards, --ww _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
