rjc@churchy.ai.mit.edu (Ray Cromwell) (02/16/91)
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! This sounds like a bug to me, layers must be doing a forbid()/disable() for a long period of time. Graphics library does the same thing. Take the AnimOb example from the RKM's (or RKM companion disk) and run 1 or 2 of them(or at the same time). 1 of them slows your pointer(jerky). 3 of them nearly stops your pointer cold. 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. 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. My best guess is gfxlib is manipulating lots of structures, and to stop collisions, it is Forbid/Disable()ing around critical sections. Has anyone tried running the anim/anim_ex examples from the RKMs under 2.0 to see if this has changed? (use Semaphores?) I don't mind cpu hogging, but when it freezes my pointer and brings the system to a grinding halt, it's scary. I reminds me of Mac, or of a GURU coming. 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.
peter@cbmvax.commodore.com (Peter Cherna) (02/16/91)
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!"
rjc@geech.ai.mit.edu (Ray Cromwell) (02/16/91)
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.)
markv@kuhub.cc.ukans.edu (02/17/91)
>>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. Agreed. Also, do you have any FAST ram? Dont forget that the blitter is async, but only one guy can access RAM at a time. I know from very careful work, expirimentation, simple math, etc. there is just barely enough RAM cycles for the blitter to do a 2 channel operation (like copy/move or mask) per frame on 2 640*200 bitplanes when the display is the same. If you have no fast RAM and the CPU needs to do much, then you are really out of luck. Before people complain about how slow the Blitter is these days, it still sure beats nothing at all (which is still the case with 99.9% of non-Amiga desktop micros today). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~