Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!mintaka!geech.ai.mit.edu!rjc From: rjc@geech.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga.programmer Subject: Re: 1.3/2.0 Question Message-ID: <1991Feb16.011818.8632@mintaka.lcs.mit.edu> Date: 16 Feb 91 01:18:18 GMT References: <1991Feb15.193645.1315@mintaka.lcs.mit.edu> <19028@cbmvax.commodore.com> Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius) Organization: None Lines: 94 In article <19028@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >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()). Ah, I had the strange notion that the pointer was interrupt driven. Seems like intuition would benefit from being multithreaded. >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. I see what you mean. I guess I need a faster processor, or layers needs some assembly coding and optimization. >>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. Yes, QBlit looks nice. I think I'll try hacking at it. However, I got the impression that the GfxLib GEL routines are high level, hence easier to port to RTG/DIG (since they don't make many assumptions about the hardware that can't be emulated.) >> 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. If you compare the speed of the OS animate routines vs European Demos you may see my point. 1 or 2 animating bobs start to make the system jerky. I know the blitter is faster than this because I've seen European demos with literally hundreds of bobs on the screen. Perhaps WaitBlit() is the problem since it busy-waits, and gfx lib is not smart enough to do calculations in parallel while it's blitting? >>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. I commend you and the rest of the Commodore team for the tremendous work you've been doing and at the same time answering the net's questions. I heard the translator.library has been improved (and narrator.device too?) A friend of mine has one of the first A3000's with an old version of 2.0. I couldn't detect any audible improvement over 1.3,but he may not have the updated version of translator/narrator since they were within 10/20 bytes of the size of the 1.3.2 translator. Has there been a noticeable improvement in the speech? (digitized/better phonemes?) The Amiga's built in speech is one of the most untapped abilities of the machine (application wise) partially because translator wasn't great at converting speech to phonemes and narrator's phonemes weren't particulary smooth. > 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!" -- Email Address:rjc@albert.ai.mit.edu (do not mail to rjc@ai.mit.edu, the mail servers are different.)