Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!rutgers!cbmvax!peter
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: 1.3/2.0 Question
Message-ID: <19028@cbmvax.commodore.com>
Date: 15 Feb 91 21:31:40 GMT
References: <1991Feb15.193645.1315@mintaka.lcs.mit.edu>
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore, West Chester, PA
Lines: 56

In article <1991Feb15.193645.1315@mintaka.lcs.mit.edu> rjc@churchy.ai.mit.edu (Ray Cromwell) writes:
>
>  I have noticed a very annoying thing about layers/graphics.library
>lately. No it's not the slow de-dicing/rearranging that happens when
>you have lots of overlapping windows. It's the fact that when layers
>library is busy rearranging layers, the system is DEADLOCKED. I mean
>the pointer won't budge!

Much of the operation of Intuition runs on the task of the input device.
This includes the motion of the pointer and all user-initiated layering
operations (like sending a window to the back or moving a layer).  Intuition
calls layers on its own task, and while the task is busy with layers
it's not available to move the mouse.  There is no lengthy Forbid() or
Disable() involved.  In fact, layers.library has a complete efficient
semaphore-based locking protocol (cf. LockLayerInfo(), LockLayer()).

Spawning off a separate task to move the pointer (or equivalently, to
do the layer operations) is non-trivial, since they would need to
sync up often, and syncing up means one waits for the other, and
you're back to the same situation.

>If the animation routines in GfxLib pull down the system that much they
>are not very usuable (except simple-sprites). Banging on the hardware
>starts to look real good.

They do use a lot of horsepower.  They're pretty general-purpose.  There
are lots of code-it-yourself alternatives that don't involve banging
on the hardware but give you better performance with a loss of generality.

>  I don't understand how a routine to move 1 or 2 bobs across the screen
>is going to eat up almost 100% of the CPU (7mhz). After all, bobs (blitter)
>are rendered in parallel.

There still is only one blitter, and there is set-up work and so on.

>My best guess is gfxlib is manipulating lots
>of structures, and to stop collisions, it is Forbid/Disable()ing around
>critical sections.

This is not so, in general.

>  I know 2.0 underwent extensive re-writing, but just how much of 1.3
>was rewritten? I was under the impression that only intuition, workbench and
>dos.library extensive rewriting.

Almost everything got re-opened, including major work in the above three
modules, plus graphics, layers, timer, ram-disk.  Also several brand
new modules have been added.  The number of modules that are basically
unchanged from 1.3 is minute.

     Peter
--
     Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
     {uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"Oh, PIN-compatible!  I thought you wanted me to make it IN-compatible!"