🚀 go-pugleaf

mlelstv@serpens.rhein.de (Michael van Elst) writes:

>jasonb@cs.uwa.edu.au (Jason S Birch) writes:
>>>Well, that happens when you have to do calculations.

>>Only if you do the calculations at the same priority as your event
>>handling.

Note that when I said "event handling", I was referring to the actual
application processing of events, not just making the button look
depressed. I'm talking about the application's *response* to being
notified the button was depressed.

>Yes. But this isn't done by AWeb or ClassAct. It is done by MUI, most
>editors and effectively by the console in raw mode.

But this is my whole point -- because MUI *does* process GUI responses
to input events on the main task, programmers offload anything that is
computationally intensive onto another task at a lower priority so that
buttons will depress immediately when clicked. See IBrowse, AmIRC, and
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. 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.

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.

>>If AWeb put the image decoding at a lower priority itself (which is a
>>reasonable thing to do,

>That's something that you do not want. You want I/O, decoding and
>rendering done concurrently and this means: at the same priority so
>that they are timesliced.

This is not contradicting what I said. I'm happy for I/O, decoding and
*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. (I have emphasised the "rendering" because this appears
to be the part that is not offloaded onto a subtask in AWeb. If it was,
the subtask would get a lower priority and the main event loop -- which
would then be simply waiting for user input -- would quite naturally
get a higher priority. The fact that it doesn't is what causes the
delay when processing events.)

>Of course you can drop the priority of all these tasks to the same
>level. But apparently this is not what happens with Executive.

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. This satisfies your
requirement for timeslicing, except the timeslices tend to be in
quantums of one second rather than four VBLs. Non-CPU intensive tasks
are automatically raised in priority, because they are not using as
much CPU. Since application event loops (especially in current MUI
apps) tend to be non-CPU intensive, they tend to be running at a raised
priority under Executive, which is why it can make MUI apps feel so
responsive (they may not be processing button depressions at priority
20, but they're still above everything CPU intensive in the system
which, on the Amiga, gives the same effect).

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). Executive would then ensure that its priority remains above
the other tasks, keeping the whole application responsive.
Alternatively, starting the priorities of the image rendering tasks at
a lower level than the main task would have a similar effect.

>>downloading tasks are handled separately, but it appears the page
>>layout is handled by the same task that handles user interface events.

>Either that or the tasks are synchronized with semaphores.

I suspect the page layout is handled by the user interface
event-handling task because only one process shows up (AWeb) when a
big page is being layed out, and it's taking up an awful lot of CPU.

>>processing incoming events, making the whole thing feel sluggish. The
>>ironic end result is that the MUI program actually feels *more*
>>responsive.

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

>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