🚀 go-pugleaf

yrozijn@xs4all.nl (Yvon Rozijn) writes:

>Jason S Birch (jasonb@cs.uwa.edu.au) wrote:
>:
>: Which would
>: you prefer: MUI apps running the bulk of their code at pri 20 because
>: the programmer didn't know any better, or MUI apps running the bulk of
>: their code at pri 0?

>I prefer visual feedback done at priority 20, and application processing
>done at priority 0. 

I prefer, in addition, for CPU intensive code to be run at a priority
less than 0. This can usually be nicely isolated anyway (as AWeb has
done for image decoding, etc) and once that is done, using a lower
priority is trivial, and helps other processes -- whether they be a
MUI app, or a simple 'ls' -- no end.

>But with MUI it's either all at 20 or all at 0, unless
>the programmer is going into relatively much effort of doing things
>in different subtasks.

Well, it's all at 0, none at 20. The question above was a hypothetical
one: would you want the programmer to do extra work to *not* make their
MUI apps run at pri 20, or extra work to *not* make their apps run at
pri 0. Personally, I think it's a lot safer to take the latter option.
The AmigaGuide.datatype shows what can happen otherwise.

As for subtasks -- you, yourself, have already put the effort into
doing things in different subtasks, presumeably because it also makes
the programming model *simpler*, correct? You don't want to have to
stop your network transferring to do some image decoding, then a bit of
laying out, then check to see if the user has clicked on a link before
going back to network transferring again. Without using threads this
would be a nightmare to do efficiently on any given CPU. You also want
to respond to user input fairly quickly (even if you know the button
has been refreshed at pri 20) so the whole app feels responsive.
Putting the CPU intensive stuff in a thread at a lower priority than
your event loop does this.

>: If the CPU intensive tasks [AWeb] spawns ran at a lower priority, it would
>: be [more responsive].

>Interesting idea. I'll keep it in mind.

That's all I ask. :-) Well, ok, there are others which I'll include
now in case they've been lost in the other not-so-AWeb-related
postings:

When I use the arrow gadgets to move back and forth through pages in
the history, they are not progressively displayed like they were when
being transferred across the network. Big pages can take quite some
seconds to be shown, and until then AWeb blocks user input and doesn't
even allow the operation to be cancelled. Can you make cached pages
appear in the same manner as transferring pages (except, presumeably,
faster)?

The behaviour when Executive had changed the priorities of the threads
was curious. The main, event-handling process appears to also do page
layouts, yet that thread was quite clearly getting CPU time (since the
page was updated and "Top" showed it getting the CPU) but did not
respond to any events until after the page was completely finished.
When I set all the threads to run at the same priority, however, it
worked fine (although the response to events was a little sluggish).

When I was creating different sized pages earlier to see how long AWeb
took to display them, I simply created a line with 32 characters on it
and kept duplicating it. When I got to around 6k, AWeb's progress bar
at the top would show the page being loaded, but nothing would appear.
(Just 32 characters smaller and AWeb showed it fine.) By putting a
<P>...</P> pair around the 6k of text, and then duplicating that, it
worked fine up until 384k (the largest I tested).

Can anything be done about the flickering of form gadget borders when
typing into them?

Finally, when is full Java support going to be included. ;-)

Otherwise, AWeb is a good browser. Well done.

> -<_>- Yvon   : | ==| yrozijn@  : >WWW< xs4all.nl/  : === ) Amiga
>  / \  Rozijn : `---' xs4all.nl :  /|\  ~yrozijn    :     O  4000

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