roddi@bruce.cs.monash.OZ.AU (Roddi Walker) (03/26/91)
Hi! I was at a developer friend's house a few days ago, playing with WB 2.0. While it is a huge advance over 1.3, I notices a few nasty things happen when fooling around with 10-20 windows, all roughly stacked over each other. First, the updates are SSLLLOOOOOOWWWWWWW - if I close/move/whatever a window, I have to wait 10+ seconds for the mouse to unfreeze and the update/redraw to finish. It was this slow in 1.3, but I had hoped things would have sped up under 2.0 (this is on a 68000 A2000 with lots of ram, btw). True, people normally fool around with 1-7 (say) windows, but this is a nasty limitation. Just out of interest, I tried the same thing on a nasty 8MHz 68000 Mac Plus, and its performance (for window redrawing) was MUCH BETTER - Not appreciably slower than when it was redrawing just a couple of windows. I would guess that the Mac uses a much smarter algorithm - not only is it unquestionably MUCH faster, but I also don't see poorly refreshed windows on the Mac as I do under WB 1.3 (sometimes). Also, when 2.0 was redrawing the windoes, it would often leave vertical/horizontal 1 pixel wide/thick gaps when redrawing the window borders (the box with the scroll bars) and the little rectangle around the icons within the window. All in all, annoying but non-fatal bugs, but they do lower my opinion of 2.0 - I still think the current Mac interfaces are slicker, at least aesthetically, than 2.0 (but there is NO WAY I would give up multitasking, CLI windows, and a GUI that runs in about 150K (once kickstart is in ROM)). Any comment from the folks at Commodore? (There's NO USE talking to CBM Australia - biggest pack of losers I have ever seen - they're still not on the Internet, though it has been in the pipeline for a LOOOONNNGGG time). Roddi.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/26/91)
In article <3877@bruce.cs.monash.OZ.AU> roddi@bruce.cs.monash.OZ.AU (Roddi Walker) writes: > First, the updates are SSLLLOOOOOOWWWWWWW - if I close/move/whatever >a window, I have to wait 10+ seconds for the mouse to unfreeze and the >update/redraw to finish. There was one intermediate beta version of past-2.02 that was said to have such problems. But as far as I know, this is already fixed. > Just out of interest, I tried the same thing on >a nasty 8MHz 68000 Mac Plus, and its performance (for window redrawing) >was MUCH BETTER Unbelievable :-) > All in all, annoying but non-fatal bugs, but they do lower my >opinion of 2.0 - I still think the current Mac interfaces are slicker, >at least aesthetically, than 2.0 (but there is NO WAY I would give up >multitasking, CLI windows, and a GUI that runs in about 150K (once kickstart >is in ROM)). You should compare only final, completed, released OS versions. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
scroll@reef.cis.ufl.edu (Steve Croll) (03/27/91)
In article <3877@bruce.cs.monash.OZ.AU> roddi@bruce.cs.monash.OZ.AU (Roddi Walker) writes: >...................... I would guess that the Mac uses a much smarter >algorithm - not only is it unquestionably MUCH faster, but I also don't >see poorly refreshed windows on the Mac as I do under WB 1.3 (sometimes). In my (limited) experience with a Mac, it seems that before a window is rendered into, it is brought to the front if it is not already there. I would *guess* that this is done to simplify clipping. It may be faster, but it is probably not smarter and it is definitely not as flexible as the way the Amiga does things. As for wanting the Amiga to be faster in this area, I agree. But not at the expense of flexibility. I absolutely *HATE* it when the Mac decides the "best" window arrangement for me. -- -- Steve Croll (internet: scroll@reef.cis.ufl.edu home: 904-373-8389)
roddi@bruce.cs.monash.OZ.AU (Roddi Walker) (03/27/91)
In <1014@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <3877@bruce.cs.monash.OZ.AU> roddi@bruce.cs.monash.OZ.AU (Roddi Walker) writes: >> First, the updates are SSLLLOOOOOOWWWWWWW - if I close/move/whatever >>a window, I have to wait 10+ seconds for the mouse to unfreeze and the >>update/redraw to finish. >There was one intermediate beta version of past-2.02 that was said to >have such problems. But as far as I know, this is already fixed. >> Just out of interest, I tried the same thing on >>a nasty 8MHz 68000 Mac Plus, and its performance (for window redrawing) >>was MUCH BETTER >Unbelievable :-) I think the speed difference has more to do with the processor used, rather than the processor/hardware (we all know the Amiga BLOWS AWAY Macintii for graphics ... it takes a 25MHz 386 PC with a good VGA to come close ... and still there's that god-awful sound ... on an unrelated note, it's interesting to hear IBM owners say (after watching the latest BudBrains demo) "It'd be SO easy to write than on an IBM" ... yeah, sure, why haven't I seen any ...) >> All in all, annoying but non-fatal bugs, but they do lower my >>opinion of 2.0 - I still think the current Mac interfaces are slicker, >>at least aesthetically, than 2.0 (but there is NO WAY I would give up >>multitasking, CLI windows, and a GUI that runs in about 150K (once kickstart >>is in ROM)). >You should compare only final, completed, released OS versions. True. I wait with bated breath for 2.0's final, triumphant release ... maybe 9 months from now ... sigh ... If this is fixed, there will be none happier than me :-) >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk Roddi Walker
jesup@cbmvax.commodore.com (Randell Jesup) (03/27/91)
In article <3877@bruce.cs.monash.OZ.AU> roddi@bruce.cs.monash.OZ.AU (Roddi Walker) writes: > I was at a developer friend's house a few days ago, playing with >WB 2.0. While it is a huge advance over 1.3, I notices a few nasty things >happen when fooling around with 10-20 windows, all roughly stacked over each >other. Note that the release is likely to considerably different than a developer-only beta. > First, the updates are SSLLLOOOOOOWWWWWWW - if I close/move/whatever >a window, I have to wait 10+ seconds for the mouse to unfreeze and the >update/redraw to finish. It was this slow in 1.3, but I had hoped things >would have sped up under 2.0 (this is on a 68000 A2000 with lots of ram, >btw). True, people normally fool around with 1-7 (say) windows, but this >is a nasty limitation. Just out of interest, I tried the same thing on >a nasty 8MHz 68000 Mac Plus, and its performance (for window redrawing) >was MUCH BETTER - Not appreciably slower than when it was redrawing >just a couple of windows. I would guess that the Mac uses a much smarter >algorithm - not only is it unquestionably MUCH faster, but I also don't >see poorly refreshed windows on the Mac as I do under WB 1.3 (sometimes). What's really going on here is that the mac doesn't allow anything to draw into an unexposed window (notice how windows pop to the front when you activate them?) So it doesn't have to save off-screen bitmaps, and doesn't have to worry much about clipping rectangles - only visible portions count. Also, work has been done on layers to improve performance (and it has been improved considerably from earlier 2.0 versions), but the basic algorithms required to handle multitasking, (partially) obscured windows have an exponential component in the recalculation of the clipping rectangles. > Also, when 2.0 was redrawing the windoes, it would often leave >vertical/horizontal 1 pixel wide/thick gaps when redrawing the window >borders (the box with the scroll bars) and the little rectangle around the >icons within the window. I haven't seen anything like this (if I read it right, it's confusingly worded) in any recent version. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (03/27/91)
In article <20150@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <3877@bruce.cs.monash.OZ.AU> roddi@bruce.cs.monash.OZ.AU (Roddi Walker) writes: >> I was at a developer friend's house a few days ago, playing with >>WB 2.0. While it is a huge advance over 1.3, I notices a few nasty things >>happen when fooling around with 10-20 windows, all roughly stacked over each >>other. > > Note that the release is likely to considerably different than a >developer-only beta. > >> First, the updates are SSLLLOOOOOOWWWWWWW - if I close/move/whatever >>a window, I have to wait 10+ seconds for the mouse to unfreeze and the >>update/redraw to finish. It was this slow in 1.3, but I had hoped things >>would have sped up under 2.0 (this is on a 68000 A2000 with lots of ram, >>btw). True, people normally fool around with 1-7 (say) windows, but this >>is a nasty limitation. Just out of interest, I tried the same thing on >>a nasty 8MHz 68000 Mac Plus, and its performance (for window redrawing) >>was MUCH BETTER - Not appreciably slower than when it was redrawing >>just a couple of windows. I would guess that the Mac uses a much smarter >>algorithm - not only is it unquestionably MUCH faster, but I also don't >>see poorly refreshed windows on the Mac as I do under WB 1.3 (sometimes). > > What's really going on here is that the mac doesn't allow anything >to draw into an unexposed window (notice how windows pop to the front when >you activate them?) So it doesn't have to save off-screen bitmaps, and doesn't >have to worry much about clipping rectangles - only visible portions count. >Also, work has been done on layers to improve performance (and it has been >improved considerably from earlier 2.0 versions), but the basic algorithms >required to handle multitasking, (partially) obscured windows have an >exponential component in the recalculation of the clipping rectangles. > >> Also, when 2.0 was redrawing the windoes, it would often leave >>vertical/horizontal 1 pixel wide/thick gaps when redrawing the window >>borders (the box with the scroll bars) and the little rectangle around the >>icons within the window. > > I haven't seen anything like this (if I read it right, it's confusingly >worded) in any recent version. I have a suggestion. How about a new layer type called DUMB_REFRESH. DUMB_REFRESH layers would store the entire window offscreen instead of just the hidden parts. Intuition should use DUMB_REFRESH windows as default until a memory pannic(AllocMem()) occurs, then intuition would convert a few DUMB layers into SIMPLE/SMART ;layers. The Mac's system is less memory efficient, but faster. I feel the AMiga should offer both. Speed, and then memory efficiency. You could also make DUMB_REFRESH a preferences option, and people with gobs ram could opt to activate it. I don't know how cuts/clipping of dumb layers would work tho. OA>-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) -- /~\_______________________________________________________________________/~\ |n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| |~| .-. .-. |~| |_|________________________________| |_| |________________________________|_|
roddi@bruce.cs.monash.OZ.AU (Roddi Walker) (03/28/91)
In <20150@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > What's really going on here is that the mac doesn't allow anything >to draw into an unexposed window (notice how windows pop to the front when >you activate them?) So it doesn't have to save off-screen bitmaps, and doesn't >have to worry much about clipping rectangles - only visible portions count. >Also, work has been done on layers to improve performance (and it has been >improved considerably from earlier 2.0 versions), but the basic algorithms >required to handle multitasking, (partially) obscured windows have an >exponential component in the recalculation of the clipping rectangles. oh. hum, all the time CBM is holding the beta and its getting better and better (and more stable :-) I WANT IT! Waahhhh!! >> Also, when 2.0 was redrawing the windoes, it would often leave >>vertical/horizontal 1 pixel wide/thick gaps when redrawing the window >>borders (the box with the scroll bars) and the little rectangle around the >>icons within the window. > I haven't seen anything like this (if I read it right, it's confusingly >worded) in any recent version. Um, it *is* rather tricky to drescribe ... they say a picture is work 1K words (ie. 2048 bytes, I guess). So here goes: +---------------------+-+ | <window 1> |X| | |X| | +------------------+-+ | | <window 2> |X| | | |X| X == scroll bar :-) | | |X| | +------------------+-+ | |X| +---------------------+-+ after window 2 has been moved/closed whatever: +---------------------+-+ | <window 1> |X| | |X| | |X| | * X <- imagine this gap is 1 | * |X| pixel wide | * |X| | |X| | |X| +---------------------+-+ sometimes this happens to the rectangles of icons that were under window 2, except a pixel is missing from both vertical sides of the rectangle, on the same scan line. * == random 1 pixel wide junk, where the edge of widow 2 used to be. * * Sometimes this junk can be horizontal, in which case it is 1 pixel high. Ah well, these bugs are probably fixed in the current beta anyways ... >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) ^^^ not as cool as your previous sig(the one about the compiler :-) which is the second coolest sig I have ever seen (the coolest was: Jesus saves ... but Gretzky catches the rebound ... he shoots ... he SCOORES! (yes, I know Gretzky is a hokey player, but I'm not into basket ball)). How about: The Sun rises over my source code, I am at peace ;-) Roddi
jesup@cbmvax.commodore.com (Randell Jesup) (03/30/91)
In article <1991Mar27.081942.3874@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > I have a suggestion. How about a new layer type called DUMB_REFRESH. >DUMB_REFRESH layers would store the entire window offscreen instead of >just the hidden parts. Intuition should use DUMB_REFRESH windows >as default until a memory pannic(AllocMem()) occurs, then intuition would >convert a few DUMB layers into SIMPLE/SMART ;layers. It's in there: SUPERBITMAP windows. Since 1.0. Eats lots of memory. > The Mac's system is less memory efficient, but faster. I feel >the AMiga should offer both. Speed, and then memory efficiency. >You could also make DUMB_REFRESH a preferences option, and people with >gobs ram could opt to activate it. That's NOT how the mac does it. The mac uses the equivalent of extra-simple simple refresh windows. No non-visible portions are stored by the MacOS. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
peter@sugar.hackercorp.com (Peter da Silva) (04/01/91)
I'm sure that the statements made here that the Mac only renders into the front-most layer are incorrect. Mac windows are all equivalent to the Amiga's SIMPLE_REFRESH windows: they do not keep any off-screen backing-store. Window handling is a strong point of the Amiga's system software. Both 1.3 and the latest 2.0 are way faster than the Mac, simply because the overhead of multitasking is so low and because the overhead of SMART_REFRESH windows is lower (just blit in the exposed portions of the display, instead of waking up every application involved and waiting for it to repaint those parts of the window. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.