Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!tcdcs!maths.tcd.ie!ecarroll
From: ecarroll@maths.tcd.ie (Eddy Carroll)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Some WB2.0 Peeves
Message-ID: <1991Jun29.055816.25791@maths.tcd.ie>
Date: 29 Jun 91 05:58:16 GMT
References: <1991Jun28.025117.23230@ncsu.edu> <1991Jun28.065023.1581@mintaka.lcs.mit.edu> <1991Jun28.095803.15224@ncsu.edu>
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Lines: 116

My first comp.sys.amiga.advocacy posting. I hope this doesn't become a
habit :-)

In article <1991Jun28.095803.15224@ncsu.edu> kdarling@hobbes.catt.ncsu.edu
(Kevin Darling) writes:
>rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>> Kevin, you're being silly. The Amiga doesn't stop when you pull down
>> a menu, only rendering is blocked on the current screen. 
>
>The process(es) rendering are blocked as long as the user fiddles around;
>so whooops... out goes any benefits of preemptive multitasking for them.

Let's be realistic here. The majority of programs that render in the background
are of the ray-tracing/fractal/animation variety and will be rendering to their
own screen anyway. You're unlikely to be playing with the menus of these
programs while they're rendering; you just start them off and then go on to
something else. Most of the windows on, say, the Workbench screen are either
idle or only outputting every now and again. In both cases, the occasional
locking of layers has little or no impact on the program.

>> Let's say a program needs to get at a shared system structure and it
>> obtains a semaphore lock on that structure, is the machine flaking out when
>> another task is put to sleep that also tries to access the same structure
>> and can't get the semaphore it wants?
>
>If the structure you're talking about is a large chunk of shared memory,
>then it would be wasteful to lock ALL of it out to access just a tiny piece.
>In a similar fashion, there's no need to lock down an entire screen just
>so some tiny window movement outlines (or even a menu) can be displayed.
>Unless, of course, you're taking the quick and dirty way out :-)

It's all a matter of balance. Consider the way most users tend to use menus;
they call up the menu bar and then browse through menus until they spot the
item they want, before finally selecting it. Without doing tests, I'm willing
to bet that there would be a very noticeable decrease in speed when browsing
menus if rendering a menu involved creating a new layer. (For a start, all
the layers underneath have to be split, and since most windows on the Amiga
are Smart Refresh, they have to be set up for offscreen rendering too).  All
of which makes the system feel that much less responsive to the user.  An
A3000 might handle it comfortably but the window system was designed for the
original A1000. I think the current way of handling menus fits in nicely with
the "Lean & Mean" approach to the rest of the system.

>> So let's assume you just dragged a window. You are blocking a task
>> from rendering to _that one screen_ for about 1 second. Hardly
>> a performance loss. 
>
>                   You dare to mock other machines which block their cpu
>during disk accesses and so forth, and yet defend this Amiga behavior??
>[Gomer Pyle voice as only a TarHeel can]  For shame, for shame, for shame!

Now, now. It's hardly fair to compare disk access to menu rendering. Programs
can go to disk for lots of things independently of the user, whereas menu
rendering only ever occurs as a result of the user playing with the mouse.
And often when the user goes to pick a menu item, the program being affected
is waiting for input anyway.

>> Perhaps you don't understand the full implications of making menus
>> into layers. [short list deleted]
>
>[wry voice]  Yes, I guess since I implemented overlapping windows in a
>few hundred bytes on a 6809 multitasking machine, I "don't understand".

Hey, isn't it cheating to argue in .advocacy if you _do_ know what you're
talking about? :-)

>Hey, I can't help it if the Amiga layers library is slow and cumbersome.

Hmm... another good reason to lock layers and go directly to the screen.
(Layers.library does tend to degenerate badly if you have lots of
layers/windows active, sigh.) What method did you use to handle overlapping
windows on the 6809?

>> Something like Imagine which has a seperate task for rendering won't even
>> be affected. Multi-threaded apps in general won't be affected. 
>
>True.  How many apps work that way, tho?  Better be ALL of them, or
>my point still stands :-)

Since Intuition renders menus asynchronously to applications, they don't have
to be multithreaded at all (although it's no harm).

>>>Under ver3.0 of OS-9 for the 6809-based CoCo-3, neither window moves/resizes
>>>nor menu pulldowns stop any of the other windows from continuing output.
>>>(Altho the menus were easy: they are contained per window, not at the top :)

Sounds nice. Surely it does nasty things to the mouse feedback during
moving/resizing though (i.e. the window outline doesn't keep up with the
pointer too well since it's constantly crossing over a rendering window)?

[ Cool stuff about dragging windows across screens deleted. Sounds like an
  Amiga hack just waiting to be written. Any takers? Davide Cervone perhaps? ]

>Anyway: is keeping full multitasking worth the possibly slower background
>rendering?  My answer was/is emphatically Yes.  Otherwise you could stretch
>and stretch and decide that well, locking for a minute might be okay, too.
>None of that fits in with the superiority of preemptive multitasking tho, eh?

Well, my answer is No (for the current version of Intuition, at least).
Everything in moderation. While locking layers for a long period of time is
certainly very unfriendly, menu selections tend to last only a few seconds
at most. Not to mention the nice side effect of being able to use the RMB to
temporarily pause output to the screen :-)

Still, maybe someone can hack up PopUpMenu to use the slower method and
prove you right (and me wrong).

By the way, what do you do in real life, Kevin? You seem to get to play with
lots of nice hardware (slightly envious... :-)

Regards,
Eddy
-- 
Eddy Carroll           ----* Genuine MUD Wizard  | "You haven't lived until
ADSPnet:  cbmuk!cbmuka!quartz!ecarroll           |    you've died in MUD!"
Internet: ecarroll@maths.tcd.ie                  |   -- Richard Bartle