Subject: Re: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe maalis 10 2000 - 17:09:01 EST
>Sounds good. But we yet to have to solve the problem that a GTK (say) level
>meter should have larger priority than any other GUI task.
>
>I have planned to have one service which gets all GUI requests and
>which routes the commands to GUIs.
>
>If nothing is done for this, then a slider move, a waveform graphing
>(whatever) could jam level meters. If necessary, too much delayed
>GUI requests (such as waveform graphing) should simply removed
>from the queue.
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.
Ardour has (say, 26) level meters updating at 100Hz right now, and
using a slider does not cause any "hogging" of the processor/X server:
all that happens is that each X event (mouse motion) gets handled 1 at
a time, and then control returns to the main loop. You may be
confusing this with situations where an X event causes "heavy"
computation or thread blocking to occur, preventing a return to the
main loop. This is a different problem, one that has to be handled
with good GUI internal design so that it basically cannot happen. The
GUI thread should never block, except when waiting for X events. This
takes some work (yep, getting the meters to keep running while ardour
loads a "tape" was pretty tricky and is still not quite right), but it
can always be done.
A mouse can't generate much more than 100 events per second in my
experience, and even less if you use motion hints. There is therefore
plenty of time for doing other GUI work, regardless of what the X
events are controlling (knobs, sliders, etc.)
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST