🚀 go-pugleaf

jasonb@cs.uwa.edu.au (Jason S Birch) writes:

>AmFTP for examples of this. As a side effect, because MUI doesn't show
>a button being depressed unless it is also about to process it, those
>applications also give an immediate response to those events.

Sounds really useful if the button doesn't react.

>This is
>in contrast to AWeb, which *does* show the button being depressed
>immediately, but the actual processing of the event can take a second
>or two, so it feels sluggish.

What would you think about a keyboard where the keys are stuck until
a program reads from the keyboard ?

Obviously you want to be able to press keys on the keyboard and you
accept that the characters might appear _a little later_. Same with
gadgets and mouseclicks. The problem is one of _time_. You expect
some things to happen immediately, other things are acceptable when
delays for a fraction of a second, other things are allowed to take
seconds, minutes, hours, whatever. The trick is to provide appropriate
feedback.

And with the gadgets running completely on the user process you cannot
provide the feedback all the time. It depends on how fast your machine
is, how much work your program has to do and wether other _user
processes_ are using up CPU time.

It is much simpler to provide timely feedback if the user interface
runs at a higher priority. And that's what the Amiga and Intuition
does, it has a user interface process run by input.device.

Obviously this has a disadvantage since many user interfaces also
perform low priority actions. So you need at least part of the interface
running on the high priority process and offload part of the interface
to a low priority task. This can be a new task (but which possibly
needs complex locking of data structures) or the user program (but which
might interfere with long term calculations).

>Obviously, because of the way MUI works, a program written in exactly
>the same way AWeb has been, but using MUI instead, would be even
>worse, because the buttons themselves wouldn't depress for a second or
>two. The point is (good) programmers don't program in MUI in the same
>way. They use a subtask or put the application to sleep.

And they have to raise the priority of the user interface to be safe
against other user processes. Usuability of the user interfaces and
other real-time tasks now becomes the policy of individual programs
and their programmers.

>*rendering* to be done concurrently, just as long as they're done
>concurrently at a lower priority than the main application's event
>handling loop.

With the standard Exec scheduler you can even allow it to run on
the same priority. The maximum latency (assuming that the UI doesn't
need more than one timeslice) is the number of processes that run
concurrently multiplied by the length of the timeslice. With the
current timeslice value it should be reasonable to have 3 or 4 other
process with little influence on the event handling. For many event
types you can even allow larger delays but that's probably not
acceptable for something like a scrollbar (assuming that the event
handler has to cause updates to the display).

>would then be simply waiting for user input -- would quite naturally
>get a higher priority.

But the event handling is already done at a higher priority. What you
want to do is to do some dummy event handling at priority 20 and then
the real event handling at priority 0 (where it has to compete with
other user tasks because not everyone wants to adapt his programs to
not interfere with MUI).

>Executive dynamically adjusts the priorities every second so that, over
>time, several CPU-intensive tasks (originally at the same priority)
>will indeed get equal amounts of CPU time.

That would mean that Executive always keeps the processes at the same
priority. Obviously it doesn't do this and the timeslice of 1 second
is probably too long.

>Non-CPU intensive tasks
>are automatically raised in priority, because they are not using as
>much CPU.

And how would you handle processes that need a lot of CPU and are
scheduled a lot ?

>All it would take would be for the main event-handling task of AWeb
>not to do any heavy processing (it currently appears to do page
>layouts).

So we now have to write our programs to make MUI happy and have
to write programs to make Executive happy. Isn't this the wrong way.

>big page is being layed out, and it's taking up an awful lot of CPU.

awful ? because it doesn't keep Executive happy ?

>>I can't see that MUI feels responsive when I click on a gadget and
>>do not get any feedback.

>You've experienced this with one of the three apps I mentioned above?

Yes. And no, I do not run Executive anymore.

Regards,
-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."