Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!mintaka!geech.gnu.ai.mit.edu!rjc From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Some WB2.0 Peeves Message-ID: <1991Jun28.065023.1581@mintaka.lcs.mit.edu> Date: 28 Jun 91 06:50:23 GMT References: <1991Jun25.112729.27772@mintaka.lcs.mit.edu> <14296@goofy.Apple.COM> <1991Jun28.025117.23230@ncsu.edu> Sender: news@mintaka.lcs.mit.edu Organization: The Internet Lines: 89 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! 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 > 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 * /