taab5@isuvax.iastate.edu (Marc Barrett) (06/24/91)
I do most of my computer-related work at school on DECstation 3100. One of the things I have noticed is that on this system, when the mouse is moved to the top of a window and a menu is pulled down (I use DECterm, which has menus), any motion going on in the current window does not stop. (If a bunch of text is scrolling, it keeps on scrolling, for instance). Also, if a window is moved, the program controlling that window stops, but any animation in other windows keeps on moving. My question is: why can't this be so on an Amiga? With WB2.0 (or 1.3 or whatever), when you pull down a menu or drag a menu or icon or whatever, all animation in motion on the current screen stops. I guess I don't quite understand why this has to be on a computer with such awesome animation as an Amiga. ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) (06/24/91)
In article <1991Jun23.210647.20152@news.iastate.edu> taab5@isuvax.iastate.edu writes: > > I do most of my computer-related work at school on DECstation 3100. One >of the things I have noticed is that on this system, when the mouse is moved >to the top of a window and a menu is pulled down (I use DECterm, which has >menus), any motion going on in the current window does not stop. (If a >bunch of text is scrolling, it keeps on scrolling, for instance). Also, >if a window is moved, the program controlling that window stops, but any >animation in other windows keeps on moving. > > My question is: why can't this be so on an Amiga? With WB2.0 (or 1.3 >or whatever), when you pull down a menu or drag a menu or icon or whatever, >all animation in motion on the current screen stops. I guess I don't quite >understand why this has to be on a computer with such awesome animation as >an Amiga. It has nothing to do with processor power, it has to do with design. Intuition is single-thread (or dual depending on how you look at it) Some things run on the input.device's task, other's run on the application's task. When intuition has a menu up, it has to lock the current screen otherwise the application could render to the screen and screw up the menu's being displayed. The "problem" could probably be solved by making a menu-handling task and making windows have their own layers. This is as big a problem as you make it. Dragging windows is only done for a fraction of a second, and no one holds down a menu for a half hour. Also, this has no effect on other screens, only the current screen is affected. More often than not, I am irrated by programs that update the screen while a requester up, so menu's would probably be worse. Imagine a program outputting lots of text while you choosing a menu option, you'd have to let go of the menu so you can read the stuff before it scrolls off the window. Also, I use the right mouse button to pause scrolling! This is the #1 reason not to change it. [I could be wrong in my assumptions since I'm only making an educated guess, so perhaps Peter Cherna can elaborate.] > ------------------------------------------------------------- > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / >/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / >------------------------------------------------------------ >\ The great thing about standards is that / > \ there are so many of them to choose from. / > ------------------------------------------------------- -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
dinn@ug.cs.dal.ca (Michael 'Moose' Dinn) (06/24/91)
In article <1991Jun23.210647.20152@news.iastate.edu> taab5@isuvax.iastate.edu writes: >to the top of a window and a menu is pulled down (I use DECterm, which has >menus), any motion going on in the current window does not stop. (If a >bunch of text is scrolling, it keeps on scrolling, for instance). Also, > My question is: why can't this be so on an Amiga? With WB2.0 (or 1.3 >or whatever), when you pull down a menu or drag a menu or icon or whatever, Get NeXTWindows and PopUpMenus... both are PD. NeXTWindows makes the screeen continue when a window is moved, I believe PopUpMenus will let the screen keep going with a menu down... -- Michael Dinn, Sysop of the Moose's Swamp - Nova Scotia's largest Amiga BBS +1 (902) 463-0483, 3/12/24/48/96/14,400 baud * 290 Megabytes online Home: moose%swamp%banke1@cs.dal.ca (Amiga1000 running UUCP/BBS) School: mdinn@ac.dal.ca, dinn@ug.cs.dal.ca | These are my opinions and Work: 01Moose@dalac.bitnet IRC-Op: Moose | noone else's. (blame me :-)
jbickers@templar.actrix.gen.nz (John Bickers) (06/24/91)
Quoted from <1991Jun23.210647.20152@news.iastate.edu> by taab5@isuvax.iastate.edu (Marc Barrett): > My question is: why can't this be so on an Amiga? With WB2.0 (or 1.3 > or whatever), when you pull down a menu or drag a menu or icon or whatever, > all animation in motion on the current screen stops. I guess I don't quite Does this DEC thing have multiple screens? > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
peter@Sugar.NeoSoft.com (Peter da Silva) (06/24/91)
In article <1991Jun23.210647.20152@news.iastate.edu> taab5@isuvax.iastate.edu writes: [screen not locked while doing window handling under X windows] > My question is: why can't this be so on an Amiga? In a word: overhead. There are good reasons why the Amiga window system is more responsive on an Amiga 500 than X on a SparcStation 1. This is one of them. On the Amiga, menus are handled specially to cut down layer creation and screen fragmentation. Moving the window outline is done similarly, for the same reason. > I guess I don't quite > understand why this has to be on a computer with such awesome animation as > an Amiga. There are slight performance differences between a MIPS R3000 and a 7 MHz 68000. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
cpca@marlin.jcu.edu.au (Colin Adams) (06/25/91)
In article <1991Jun24.000524.378@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jun23.210647.20152@news.iastate.edu> taab5@isuvax.iastate.edu writes: >> >> My question is: why can't this be so on an Amiga? With WB2.0 (or 1.3 >>or whatever), when you pull down a menu or drag a menu or icon or whatever, >>all animation in motion on the current screen stops. I guess I don't quite >>understand why this has to be on a computer with such awesome animation as >>an Amiga. > > It has nothing to do with processor power, it has to do with design. > [stuff deleted explaining why] >the current screen is affected. More often than not, I am irrated by >programs that update the screen while a requester up, so menu's would >probably be worse. Imagine a program outputting lots of text while you >choosing a menu option, you'd have to let go of the menu so you can read the >stuff before it scrolls off the window. Also, I use the right mouse >button to pause scrolling! This is the #1 reason not to change it. I find this LockLayer call very annoying. If you are using WB to copy files to a disk using the slow FFS (fu*cked/fraged file system), the files are displayed in a window as they are copied. Also I may be formating a disk in another window. Everything stops if you move a window, or access a menu. Put simply it sucks, and I hope it gets fixed sometime in the distant future (C= have more important things to do I'm sure). (I know I could copy files with the quiet option, but it's nice to know where you're up to) BTW, Why on earth didn't C= come up with a decent file system? The FFS is no better (I can't tell any difference) for floppies and is the worst file system I have ever seen. Having studied and implemented some real file systems I'd like to know where C= copied their's from and WHY? >> ------------------------------------------------------------- >> / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / >>/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / >/ INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ >| INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| >\ UUCP:uunet!tnc!m0023 * / -- Colin Adams Computer Science Department James Cook University Internet : cpca@marlin.jcu.edu.au North Queensland 'And on the eighth day, God created Manchester'
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) (06/25/91)
In article <1991Jun25.032545.7153@marlin.jcu.edu.au> cpca@marlin.jcu.edu.au (Colin Adams) writes: >In article <1991Jun24.000524.378@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>In article <1991Jun23.210647.20152@news.iastate.edu> taab5@isuvax.iastate.edu writes: >>> >>> My question is: why can't this be so on an Amiga? With WB2.0 (or 1.3 >>>or whatever), when you pull down a menu or drag a menu or icon or whatever, >>>all animation in motion on the current screen stops. I guess I don't quite >>>understand why this has to be on a computer with such awesome animation as >>>an Amiga. >> >> It has nothing to do with processor power, it has to do with design. >> [stuff deleted explaining why] >>the current screen is affected. More often than not, I am irrated by >>programs that update the screen while a requester up, so menu's would >>probably be worse. Imagine a program outputting lots of text while you >>choosing a menu option, you'd have to let go of the menu so you can read the >>stuff before it scrolls off the window. Also, I use the right mouse >>button to pause scrolling! This is the #1 reason not to change it. > >I find this LockLayer call very annoying. If you are using WB to >copy files to a disk using the slow FFS (fu*cked/fraged file system), the >files are displayed in a window as they are copied. Also I may be >formating a disk in another window. Everything stops if you move a >window, or access a menu. Put simply it sucks, and I hope it gets >fixed sometime in the distant future (C= have more important things to >do I'm sure). (I know I could copy files with the quiet option, but >it's nice to know where you're up to) This seems like a matter of opinion, but how long do you stay in menus or dragging a window? Do you move windows around and can't decide where to put them? (Does it look good here? no maybe it will look good over in that corner, nah, it looks better at the bottom) > >BTW, Why on earth didn't C= come up with a decent file system? The FFS >is no better (I can't tell any difference) for floppies and is the >worst file system I have ever seen. Having studied and implemented some >real file systems I'd like to know where C= copied their's from and >WHY? Hmm, the FFS seems much faster for floppies in 2.0. The filesystem has had many improvements. Why don't you tell us why it sucks? The Amiga filesystem is slower at scanning directories than it is at locating a file (e.g. a cp file1 file2 file3 file4 file5 file6 ... file40 destdir will locate all the files very quickly, but a "list" will take a while. On the opposite end, IBM dirs come up quickly, but sometimes they take a long time to open a file, like on a locate bbs with over 500 files in one of the dirs, it takes 5-9 seconds to "lock" the file down downloading. ) Also, file notification has been added. >Colin Adams >Computer Science Department James Cook University >Internet : cpca@marlin.jcu.edu.au North Queensland >'And on the eighth day, God created Manchester' -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
torrie@cs.stanford.edu (Evan Torrie) (06/26/91)
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: > This seems like a matter of opinion, but how long do you stay in >menus or dragging a window? Do you move windows around and can't decide >where to put them? (Does it look good here? no maybe it will look good >over in that corner, nah, it looks better at the bottom) Well, Amiga users always seem to want to spend a minute with the menu pulled down as soon as they get onto the non-preemptive Mac OS running a communications program :-) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
lron@easy.lrcd.com (Dwight Hubbard) (06/26/91)
In article <1991Jun25.112729.27772@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>>BTW, Why on earth didn't C= come up with a decent file system? The FFS >>is no better (I can't tell any difference) for floppies and is the >>worst file system I have ever seen. Having studied and implemented some >>real file systems I'd like to know where C= copied their's from and >>WHY? > > Hmm, the FFS seems much faster for floppies in 2.0. The filesystem has >had many improvements. Why don't you tell us why it sucks? The Amiga >filesystem is slower at scanning directories than it is at locating >a file (e.g. a cp file1 file2 file3 file4 file5 file6 ... file40 destdir >will locate all the files very quickly, but a "list" will take a while. >On the opposite end, IBM dirs come up quickly, but sometimes they take a >long time to open a file, like on a locate bbs with over 500 files >in one of the dirs, it takes 5-9 seconds to "lock" the file down downloading. >) Also, file notification has been added. I Ran Diskspeed on both Old FS floppies and FFS floppies and didn't see any significant speedup, although I could store more information on the disk. The speedup is very noticable with a faster device such as a hard drive though and I don't see where the FFS can be called anything but a real file system when there have been people claiming 1.5+Mbps on FFS hard drives on the A3000.
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/27/91)
In article <lron.5272@easy.lrcd.com> lron@easy.lrcd.com (Dwight Hubbard) writes: >In article <1991Jun25.112729.27772@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>>>BTW, Why on earth didn't C= come up with a decent file system? The FFS >>>is no better (I can't tell any difference) for floppies and is the >>>worst file system I have ever seen. Having studied and implemented some >>>real file systems I'd like to know where C= copied their's from and >>>WHY? >> >> Hmm, the FFS seems much faster for floppies in 2.0. The filesystem has >>had many improvements. Why don't you tell us why it sucks? The Amiga >>filesystem is slower at scanning directories than it is at locating >>a file (e.g. a cp file1 file2 file3 file4 file5 file6 ... file40 destdir >>will locate all the files very quickly, but a "list" will take a while. >>On the opposite end, IBM dirs come up quickly, but sometimes they take a >>long time to open a file, like on a locate bbs with over 500 files >>in one of the dirs, it takes 5-9 seconds to "lock" the file down downloading. >>) Also, file notification has been added. > >I Ran Diskspeed on both Old FS floppies and FFS floppies and didn't see any >significant speedup, although I could store more information on the disk. >The speedup is very noticable with a faster device such as a hard drive >though and I don't see where the FFS can be called anything but a real file >system when there have been people claiming 1.5+Mbps on FFS hard drives on >the A3000. Well on floppies there is not much raw transfer speed speedup, but there is a slight speed up when scanning lots of files or having 2 tasks access the disk at once (not as much "gronk gronk grind gronk"). On a harddrive the speed increase is ALOT. Especially on an A3000. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
peter@Sugar.NeoSoft.com (Peter da Silva) (06/27/91)
The "Locklayer" during menu handling is one of the reasons the Amiga window
system is so fast. Don't begrudge the trade-off.
--
Peter da Silva. `-_-' <peter@sugar.neosoft.com>.
'U` "Have you hugged your wolf today?"lsr@Apple.COM (Larry Rosenstein) (06/28/91)
In article <1991Jun25.112729.27772@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>formating a disk in another window. Everything stops if you move a >>window, or access a menu. Put simply it sucks, and I hope it gets > > This seems like a matter of opinion, but how long do you stay in >menus or dragging a window? Do you move windows around and can't decide >where to put them? (Does it look good here? no maybe it will look good I find this highly amusing, since this is the example people use to show why MultiFinder is so inferior to the Amiga O/S. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/28/91)
In article <14296@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <1991Jun25.112729.27772@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: > >>>formating a disk in another window. Everything stops if you move a >>>window, or access a menu. Put simply it sucks, and I hope it gets >> >> This seems like a matter of opinion, but how long do you stay in >>menus or dragging a window? Do you move windows around and can't decide >>where to put them? (Does it look good here? no maybe it will look good > >I find this highly amusing, since this is the example people use to show why >MultiFinder is so inferior to the Amiga O/S. The Amiga doesn't stop multitasking when a menu is put up, all that happens is the current screen is locked via semaphore which means that rendering stops on the screen in which the menu is displayed. Only tasks that are currently rendering to the SCREEN on which the menus are being displayed will block. Any background task will run without slow down. The reason graphic rendering is locked on the screen with the menu being displayed is to stop tasks from overwriting the menu. This could be prevented by making menus into layers (like windows with full clipping, etc) but this incurs a performance hit in the responsiveness of menus so it's not done. Most Amiga apps open their own screen, so while I am pulling a menu down on DeluxePaint, rendering on the workbench screen does not stop. Hence, no real problem except for nitpickers. > > >-- >Larry Rosenstein, Apple Computer, Inc. > >lsr@apple.com >(or AppleLink: Rosenstein1) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/28/91)
lsr@Apple.COM (Larry Rosenstein) writes: >>>formating a disk in another window. Everything stops if you move a >>>window, or access a menu. Put simply it sucks, and I hope it gets >> >> This seems like a matter of opinion, but how long do you stay in >>menus or dragging a window? Do you move windows around and can't decide >>where to put them? (Does it look good here? no maybe it will look good > >I find this highly amusing, since this is the example people use to show >why MultiFinder is so inferior to the Amiga O/S. Ha! <giggling insanely> Methinks both systems can go fly a kite in this area! My own opinion: a multitasking machine should _always_ multitask, not flake out simply because of some weak "cpu-speed" or "GUI speed/need" cop out. Performance issues? Make me laugh. _Any_ speed is faster than being STOPPED! 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 :) Furthermore, you can even move a window to _any_ other open gfx screen! (just "pick" it up, click around on the next-screen mouse button, and click the window back down wherever). Try that, y'all! ha! HA! HAHA! HAHAHAHA! Harumph! Wimp excuses, everywhere. Kevin <kdarling@catt.ncsu.edu> Yes, I coded it. So sue me. :-)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/28/91)
In article <1991Jun28.025117.23230@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >lsr@Apple.COM (Larry Rosenstein) writes: >>>>formating a disk in another window. Everything stops if you move a >>>>window, or access a menu. Put simply it sucks, and I hope it gets >>> >>> This seems like a matter of opinion, but how long do you stay in >>>menus or dragging a window? Do you move windows around and can't decide >>>where to put them? (Does it look good here? no maybe it will look good >> >>I find this highly amusing, since this is the example people use to show >>why MultiFinder is so inferior to the Amiga O/S. > >Ha! <giggling insanely> Methinks both systems can go fly a kite in this area! > >My own opinion: a multitasking machine should _always_ multitask, not flake >out simply because of some weak "cpu-speed" or "GUI speed/need" cop out. >Performance issues? Make me laugh. _Any_ speed is faster than being STOPPED! Kevin, you're being silly. The Amiga doesn't stop when you pull down a menu, only rendering is blocked on the current screen. 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? Semaphore locks are better than _nothing_ considering in the past, programs have Forbid() (or even worse Disable()) to access system structures that may change. Forbid() blocks all tasks, semaphore locks only block tasks that want that semaphore. The rest run free. 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. Perhaps you don't understand the full implications of making menus into layers. 1) Clipping code slows down their rendering 2) the more windows on the screen, the more clips that may be generated which may LOCK the machine far worse than a simple LockIbase() will. when layers is bogged down, the machine will become very sluggish 3) lots of layers and cliprects constantly being created will probably fragment memory horribly. 4) see #1 5) see #1 Remember, rendering menus does not turn off multitasking, the only thing it does is block the tasks _on the current screen_ that are trying to render. Something like Imagine which has a seperate task for rendering won't even be affected. Multi-threaded apps in general won't be affected. >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 :) I bet menu rendering wasn't as quick as the Amiga. >Furthermore, you can even move a window to _any_ other open gfx screen! >(just "pick" it up, click around on the next-screen mouse button, and click >the window back down wherever). Try that, y'all! ha! HA! HAHA! HAHAHAHA! This is something I'd like to see on the Amiga. With PublicScreens its very possible, it would be dangerous to put a parasite window on a App's custom screen however. I evision a 2.0 commodity which would use a hotkey to put up a list of public screens and put the currently chosen window on which screen you choose from a list. Or an Icon/Window that you click on that cycles screens and moves the current window to each one. Or, the feature is added to the system as default using a new screen titlebar gadget. >Harumph! Wimp excuses, everywhere. Kevin <kdarling@catt.ncsu.edu> > Yes, I coded it. So sue me. :-) I can't tell whethe ryou were joking in this post or not Kevin, but surely you understand how the various Amiga locking mechanisms work to make shared access to structures atomic. On the Mac it's not a problem since the currently running at owns the CPU and nothing can interupt it while it's mucking with whatever globals it wants to. On the Amiga however, preemptive multitasking has methods to make accesses atomic. Aha! I finally discovered why the Mac doesn't have preemptive multitasking. I bet lots of Mac apps have free access to system globals, and none of them use locking/Forbid() type mechanisms so adding preemptive multitasking to the Mac might break some programs. (Imagine right in the middle of accessing a pointer somewhere another app changes the pointer, boom!) Standard Mac apps essentially run in the "forbidden" state (no other task gets the cpu until it releases it via some system call.) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/28/91)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >>My own opinion: a multitasking machine should _always_ multitask, not flake >>out simply because of some weak "cpu-speed" or "GUI speed/need" cop out. >>Performance issues? Make me laugh. _Any_ speed is faster than being STOPPED! > > 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 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 :-) > Semaphore locks are better than _nothing_ considering in the past, > programs have Forbid() (or even worse Disable()) to access system > structures that may change. Forbid() blocks all tasks, semaphore locks > only block tasks that want that semaphore. The rest run free. We're in full agreement there. > 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. Now we're not :-) 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! > 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, I can't help it if the Amiga layers library is slow and cumbersome. You _did_ have a good point about possible 68K memory fragmentation tho. Fortunately, the CoCo-3 uses an MMU. No such thing as memory frag on it! But I have to contend with such on the simpler 68K OS-9 systems <sigh>. > 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 :-) >>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 :) > > I bet menu rendering wasn't as quick as the Amiga. Now who's being "silly"? Except for any diffs because of the cpus/etc, there's no reason for menus to be drawn slower, or react slower than people. >>Furthermore, you can even move a window to _any_ other open gfx screen! >>(just "pick" it up, click around on the next-screen mouse button, and click >>the window back down wherever). Try that, y'all! ha! HA! HAHA! HAHAHAHA! > > This is something I'd like to see on the Amiga. So would I. It's way cool. Actually made the idea of windows on a multiple screen machine make _sense_ to me (I agree that multiple screens as the Amiga and CoCo have, are far easier to use & more powerful than Mac windows). BTW, since you brought up some related problems, here's what I did: when you click on the part of the window to move it, the outline box shows up as normal. Then if you hit the other mouse button (or the keyboard) and cycle thru the screens, the system simply skipped over any screen types which were bogus (on the coco: text or custom screens, or too small a space). So any screen the outline went to, was guaranteed as a good destination. > I can't tell whether you were joking in this post or not Kevin, but Well, my tone was meant to be jocular, even if the subject wasn't :-) > [....] Aha! I finally discovered why the Mac doesn't > have preemptive multitasking. I bet lots of Mac apps have free > access to system globals, and none of them use locking/Forbid() type > mechanisms so adding preemptive multitasking to the Mac might break > some programs. [...] Yah, that's the killer on most OS's which started out as singletasking. And to prevent breakage, Amigas can't use MMUs. They're both a mess :-] 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? regards - kevin <kdarling@catt.ncsu.edu> Apologies for length, too.
ecarroll@maths.tcd.ie (Eddy Carroll) (06/29/91)
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