🚀 go-pugleaf

mlelstv@serpens.rhein.de (Michael van Elst) writes:
>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.

Luckily it does. Because, as I said, CPU intensive stuff is at a lower
priority, either because the user manually lowers the priority (would
you run a raytrace at the same priority as your shell or editor? Even
before Executive came along, I took advantage of AmigaOS's scheduling
system to ensure user interface responsiveness even under a heavy
load by adjusting priorities) or because they're running something
like Executive that does the same sort of thing automatically.

>>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 ?

I'd hate it. I remember using an electric typewriter that was like
that about 12 years ago, now. Very painful.

>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.

There's no need to construct a straw man, Michael. I've already said,
right from the beginning, that the GUI should provide immediate
feedback. Never claimed otherwise. I've also already said that the way
to do it in MUI is for the programmer to ensure CPU intensive tasks
are always offloaded onto a subprocess running at a lower priority.

Hmm... And I seem to recall that the point to which you are responding
was how a particular MUI program not only visually responded
immediately to a mouseclick, but processed the mouseclick as well,
while a non-MUI program visually responded but didn't process it for
some time. Talking about how bad not visually responding to
mouseclicks is doesn't seem to follow.

>And with the gadgets running completely on the user process you cannot
>provide the feedback all the time. 

Thanks to Exec's scheduler, you can *if running at a high enough
priority*. Priority 0 is plenty high enough if CPU intensive stuff is
lower.

>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.

*And*, most importantly, their priority.

>It is much simpler to provide timely feedback if the user interface
>runs at a higher priority. 

Bingo.

>And that's what the Amiga and Intuition
>does, it has a user interface process run by input.device.

That's right, and that's wonderful. Unfortunately there are drawbacks:

>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).

Another one is wanting to have a uniform notification scheme which can
work uniformly on any attribute of any object. Running your GUI event
handling code on two separate tasks, one at pri 20 and one at the usual
pri, would make this very messy. So MUI does it all on the usual
priority task's context, which makes MUI simpler but means the
programmer has to be aware of the issues of GUI responsiveness and
ensure his event handling loop is always ready and waiting. It also
means it's more uniform -- as has been noted before, not even GadTools
does *all* it's GUI response at pri 20 -- some gadgets are refreshed by
input.device, some aren't. You even have some things -- like the
AmigaGuide datatype laying out AmigaGuide documents -- running at pri
20 when they really shouldn't be.

>>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. 

Or, to put it another way -- you can lower the priority of tasks not
directly communicating with the user. That's why you manually set the
priority of your raytracer ("doing a raytrace in the background", as
they say) below that of your editor. The total time to perform the
raytrace isn't affected, but the user interface responsiveness *is*. 
Executive simply tries to do this automatically. That's all.

>Usuability of the user interfaces and
>other real-time tasks now becomes the policy of individual programs
>and their programmers.

Only if they don't separate event handling from CPU intensive code
which disallows the user from running one of them at a lower priority.
This is true regardless of MUI or Executive. When Real3D's raytracing,
for example, I don't lower the *whole* program to -20 -- just the
DrawTasks. The program itself I keep at a normal priority so it stays
responsive. All that's required of the programmer is to provide that
separation.

BTW, both Workbench and AmiWin run themselves at priorities >0. The
notion is not new.

>>*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. 

But what do you gain from doing so? Sure, maximum latency may well be
short if you don't have too many processes, but it would be nonexistent
if those processes were just *1* below the event handling loop, and not
dependent on how busy the machine is. The beauty of Exec's scheduler
(which Executive doesn't actually change, BTW) is that higher priority
tasks will *always* get the CPU when they want. Run the event handling
loop of the task that the user is currently sending events to at a
priority of just 1 above (that's 1 higher than the others, not *at*
priority 1) other user processes in the system, and it will always be
perfectly responsive regardless of how busy the machine is.

>>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

Not for all GadTools gadgets.

>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).

Of course they don't. I'm not talking about changing AWeb so it won't
"interfere" with MUI -- I'm talking about making AWeb *itself* more
responsive, just like IBrowse -- a *MUI* app -- is. These comments
about AWeb would still be valid even if MUI never existed -- it just
so happened that a convenient example of what I was talking about was
a MUI program, and the fact that is *was* MUI made the point even more
significant given the author's comments about MUI programs in his
docs.

In case it isn't obvious -- in order for a MUI program to remain
responsive, all that's required is that no CPU intensive tasks be
competing with it for the CPU at the same priority. For GadTools, the
priority to worry about is (for most gadgets) priority 20, so it's
rarely a problem. For MUI on a typical system, it's 0 -- which means,
*for best results*, the user (or something like Executive) should ensure
that any CPU intensive tasks run at less than that. Before MUI came
along, Amiga users were always boasting about running raytracers at a
low priority and how "it didn't slow down their text editor one bit",
so the concept is not new. With Executive it can all be done
automatically.

>>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. 

Of course it doesn't. Over a long period of time they get the same
amount of CPU (all else being equal), but in one second they can get
vastly different amounts. Three CPU intensive processes will have
their priorities raised, in turn, so that every three seconds one will
get one seconds' worth of CPU. This is exactly the same as the Exec
scheduler, except Exec's dealing with much smaller quantums and makes no
effort to guess a suitable ratio of CPU between processors other than
blindly obeying the priority settings. In three seconds, each will still 
get one seconds' worth of CPU, but they would've got it in bursts of
about 0.05 seconds at a time.

>Obviously it doesn't do this and the timeslice of 1 second
>is probably too long.

Yes, I'd prefer a shorter timeslice. OTOH, shorter timeslices mean
increased overhead, and it also becomes more difficult to work out
just which tasks really are CPU intensive at all.

>>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 ?

I would make an entry for them in Executive's preferences.

>>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.

Must be a surplus of straw in Germany this year. ;-)

As I said, nothing I've said has anything to do with "making MUI
happy". MUI came into it because (a) the example programs which did it
the way I wanted happened to use MUI, and (b) MUI application
responsiveness was derided by the author in his docs, which I found
particularly ironic.

As for making Executive happy -- well, I can make an entry in
Executive for AWeb to "fix" the priorities, no problem. Simply
offloading *all* CPU intensive stuff onto a subtask would make that
unnecessary, however, and certainly doesn't hurt those *not* using
Executive -- in fact, even they might appreciate it once you got half
a dozen images decoding simultaneously and you wanted to follow a link
in a half-layed-out page.

Given he's already spawned off network transferring and image decoding
onto subtasks, is it really such a terrible thing to want page layout
there as well?

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

>awful ? because it doesn't keep Executive happy ?

Hmm... Perhaps you read more into the word than I intended. "An awful
lot", in this context, simply means "lots". No more, no less. It's a
figure of speech.

>>>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.

Well, even before I ran Executive, I always set priorities manually to
ensure processes like my editor ran higher than processes like Real3D.

>Regards,
>                                Michael van Elst
>Internet: mlelstv@serpens.rhein.de

-- 
Jason S Birch                        ,-_|\ email: jasonb@cs.uwa.edu.au
Department of Computer Science      /     \ Tel (work): +61 9 380 1840
The University of Western Australia *_.-._/ Fax (work): +61 9 380 1089
Nedlands  W. Australia  6907             v  Tel (home): +61 9 386 8630