15 Mar
2005
15 Mar
'05
6:41 a.m.
On Tuesday 15 March 2005 08:58, Olivier Guilyardi wrote:
Arnold Krille wrote:
I have a
habit of deciding wether software is good or not according to its
ability to run "fast" on slow systems, take for example the Gimp... I'm
everyday amazed by the Gimp.
And my first tests with a non-locking GUI greatly improve responsiveness on
my Duron 700mhz system. Additionally, if 1024 frames/period is the default
setting, that means it's the setting newbies will use, like musicians I
know who consider the switch from Windows and who don't have a clue what
jack is. They'll just get rpms or the like.
With 1024 frames/period I expect a 64bits quad-cpu system to show GUI
latency if I continue to lock (waiting for an ack from the RT thread) the
way I do. In this case, even the newbie will laugh.
So I think we should distinguish between locked gui and a non-locked gui
representing the real state as soon as the state is reached. Which might be a
time after the user clicked the button.
We once encountered such things in the aRts-GUI: One of our tries we did set
the volume from the mouseclick in the volumebar but did the repainting of the
volumebar after the rest of aRts informed us about the volumechange. Which
led to some slow responses of the fader...
Maybe with such big changes as deleting channels/track/whatsoever you should
recreate/update the gui after the changes are made in the engine (so after
they have an hearable effect). But to not confuse the user because nothing
changes, perhaps you could gray-out the relevant parts in the time between
starting the action and changing the gui.
Which would mean that you have a non-locked gui representing the real state of
the engine...
Did I make may thoughts clear? Its before my first coffee/tea...
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
My jackd
manpage states that the default frames/period setting is 1024,
which means that for a frame rate of 44100 Hz, I'm around 44 periods by
second, which is less than a monitor refresh. And what if some user needs
to set that up to 4096 frames/period or more ?
Wouldn't this mean that his
system is very slow or at least needs such
slow settings to run stable?
Which in turn means, he is used to slow reactions of the system / the
gui... And even if the gui reacts at once to his changes, this would
confuse him, since the sound of his changes will be noticable later...