🚀 go-pugleaf

perjac@inet.uni-c.dk (Per Jacobsen) writes:
>> It offers the following features:
>>  o AWeb doesn't use Magical User Interface (MUI). It uses BOOPSI classes
>>    instead, which results in less memory usage and increased speed.

>Are you sure about the speed? It takes several seconds from selecting the
>settings window to it actually comming up. And in 'change settings'
>window, when you click on the "chooser" gadget there is a very perceptible
>dealy before the window changes. 

The "chooser" gadget at the top of the settings window also locks my
machine up a lot. I just tried again, disabling all non-standard stuff
in my bootup, and the first time I selected it five times, choosing
different pages, before the machine locked, while the second time it
locked straight away. (A reboot is the only way out.) It clears a
rectangle to render the popup and then freezes. This is the only problem
I've found, however, and I suspect ClassAct is at fault (several of the
programs in the CA demo on Aminet crashed my machine, too).

>>  o AWeb is FAST. Tests show that AWeb is much faster than IBrowse, and
>>    slightly faster than Mindwalker and even ALynx.

>Could we see some numbers please? 

I did some tests to see if it really was faster than IBrowse (I tested
demo version 5). On several smallish pages with quite a few images,
AWeb won by about 20%, although naturally it didn't have the
backgrounds, centering, or tables (IBrowse was set to use DataTypes),
so layout was simpler. On a 600K test file (our server's access
statistics) AWeb took 157 seconds and IBrowse took 107 seconds (tested
several times to make sure changes in network traffic weren't
significant). AWeb appeared to only load the page as it formatted it,
so it was continually loading it the whole time (and didn't have any
other processes running, according to Executive), while IBrowse had a
network process that actually did the loading which finished in about
20 seconds (ethernet connection). What stood out most, however, was
that while IBrowse was loading, immediately the page started displaying
and *immediately* you could scroll up and down it. It was also very
responsive (network and image decoding process priorities are settable,
and by default are lower than the browser itself). AWeb, however, while
allowing you to click on the buttons and the scrollbar, didn't respond
to them at all until the page was completely loaded, and didn't even
allow me to abort the transfer. I found that ironic, given the
comments in the docs. Also, using the arrows to move back and forth to
that page, it doesn't display the pages at all until it's completely
formatted them - it took 17 seconds for the display to change from the
big page to the default homepage (file://localhost/PROGDIR:docs/AWeb.html) 
on an A4000/040. IBrowse changes the display almost immediately.

You might be wondering what motivated me to compare them so
thoroughly. Basically, it was in response to the claims in the docs,
which seemed to get a little "excited" at times. I couldn't work out
what eighteen steps might have been taken to get AMosaic to use its own
screen (my values ranged from four steps (click Prefs gadget; select
"System"; click "Name" popup; select screen) when a suitable screen
already existed in PSI's database, up to 12 when I added the "Prefs"
icons to the window titlebar (necessary for older apps without an
equivalent menu option) and manually set up a screen for it in PSI),
the size difference between IBrowse and AWeb isn't great, speed is
pretty close, and IBrowse definitely feels more responsive. (The
problems caused by MUI buttons being refreshed on the application's
context do exist, but - as AmIRC, AmFTP, and IBrowse demonstrate - they
should *not* be apparent to a user. Well-written MUI applications
should be multi-threaded if appropriate.) Oh, and if there was meant to
be a point to the "Shareware" comment with regards to MUI, it's lost on
me. MUI is shareware, MUI apps need MUI, but MUI app users never need
to pay for MUI - they don't even need to feel guilty about using it and
not registering. The docs say so.

But, as I said, apart from that the program itself is pretty good. It
sets out to do a job, and I think it does that job quite well. I await
future releases with interest.

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