Subject: Re: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: pe maalis 10 2000 - 18:12:32 EST
>Juhana, it seems that you might not know GTK or X too well. This is
>all handled quite normally unless you happened to have an input device
>(mouse etc.) that generated X events a lot faster than anything I know
>of.
Ok, what I really meaned is that if I'm playing several waves at the same
time in the wave editor and if all of them are auto-scrolled, then
there should be some way to organize all GUI tasks so that level meters
updates are served first and waveform graphing is skipped if necessary.
This could be a GUI service thread independent of GUI so that GUI is
not blocked.
Yep, I'm turning my wave editor to multi-threaded system so that GUI has
as fast as possible routines. Events are just quickly sent to elsewhere.
Graphing is done elsewhere and only pixmap copy is done at GUI.
I'm also thinking a complex GUI written with Gtk could slow down the
system: too many configure events etc. Would it be better to have one
drawing area where to buttons etc. are drawn? I would have total control
over what is updated and with what priority. Alternatively, I could make
the GUI with Gtk but catch, queue and prioritice events at the main window
level. Suitable callbacks could handle that. This could be a overkill
but good to know...
Applying these priorities I think one could run the program more better
with non-soft-RT processes. Even soft-RT would be in use, at least the
GUI service seems to be must.
Juhana
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST