billk@pnet01.cts.com (Bill W. Kelly) (01/14/89)
There's an annoying "bug" in the layers library that, to my knowledge, has
been in every release version of the Amiga's operating system.
I kept hoping someone at Commodore-Amiga would fix it but I suppose it's
possible that noone's noticed this. (Or that nobody cares?)
I will explain what to do to get this "bug" to appear. (BTW, don't worry--
there's no danger of crashing; this is just a visual thing.)
1) Open two FULL-SIZE SMART_REFRESH windows. (CLI windows are just fine.)
2) Fill both windows with text or graphics. (Good to get LOTS of data in
the windows. Maybe 'list c:' in one of them and 'type c:RemRAD opt H'
in the other one.)
3) Now, in one of the CLI windows, type "sdfsdaf:" and hit return.
(The object here is to put up a System Requester)
Ok, you should now have two full-size SMART_REFRESH windows open with lots
of stuff in them. You should also have a System Request asking for volume
"sdfsdaf" to be inserted in any drive. So far, so good.
Now: Start moving the System Request all over the place. Click in the drag
bar and drag it a bit and let go. Keep doing this. The more you do this
the more you will be able to see the effect of the bug.
When you get tired of moving the System Request (if you have moved it alot
-- say, fifteen to twenty times, there's no way you could miss seeing this
bug) just hit the 'Cancel' gadget to make it go away.
All you have to do now is click the front CLI window to the back.
You can keep clicking the windows in back of each other until you get
thoroughly disgusted by what you're seeing.
To get rid of this nastiness, size one of the windows small (let go) and
then size it large again.
BTW, this does NOT just happen with System Requesters. Had you opened
another CLI window that was small in size so you could drag it around like
the System Request, the result would have been the same.
What I want to know is: WHY???? I figure it must be something related to
the LayerInfo structure for the screen, since it applies to ALL
smart_refresh layers on the screen. Why does sizing a layer get rid of the
problem, while adding/deleting new layers does not???
SUGGESTION: Whatever piece of code in SizeLayer() that fixes the problem
should be duplicated and stuck in MoveLayer(). :-)
If someone could tell me why this happens and how to fix it, I'd be happy to
write a little patch that SetFunction()'s MoveLayer(). (A temporary patch --
I would think this could be fixed in 1.4?!?!!)
P.S. I guess I will attempt to describe the problem in words in case someone
for some reason or other is unable to duplicate the problem on his/her Amiga
and wonders what the heck I'm talking about.
I am guessing most of this (using the System Request as an example):
When you move the System Request around, I think a ClipRect gets set up so
that the system will know which part of the windows behind the System
Request are being obscured by the System Request. The thing is, when you
move the System Request around, parts of the old cliprects for where it USED
TO BE still remain even though the System Request has been moved to a new
location. When you move it around alot, your display gets split up into a
whole bunch of little tiny itty bitty rectangles. Then when you click the
windows to back, instead of being blitted as one big rectangle, they are
split up into all these tiny rectangles, each blitted separately. Ends up
looking nasty after a short while.
Boy, I'd sure hate to see what this would look like on a machine that didn't
have a blitter!!!! Probably take two or three seconds to do all of those
little rectangles.
Anyway, if someone can tell me why this happens and how to fix it, I'll be
very happy!
Thanx,
Bill
--
Bill W. Kelly
{nosc ucsd hplabs!hp-sdd}!crash!pnet01!billk crash!pnet01!billk@nosc.mil
billk@pnet01.cts.comewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (01/17/89)
[ This line intentionally filled with nonsense. ]
Yes, Dale knows about the problem. It's a shortcoming in the
layers.library's de-dicing routine. The routine that slices and dices
layers (VegOMatic()?), under certain conditions, doesn't quite do The Right
Thing.
A new Veg-O-Matic routine has been created for 1.4 which alleviates
this problem.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctordale@boing.UUCP (Dale Luck) (01/18/89)
In article <3704@crash.cts.com> billk@pnet01.cts.com (Bill W. Kelly) writes: > >There's an annoying "bug" in the layers library that, to my knowledge, has >been in every release version of the Amiga's operating system. Not really a bug. It is the way the dedicer coallescs contiguous cliprects when a delete operation occurs. Move and Size call create/delete. The operation of creating cliprects for layer A, then B, then C. Then deleting B is not the same as creating cliprects for layer A then layer C. The operation is non associative. communitive? or nonreversable? > >I kept hoping someone at Commodore-Amiga would fix it but I suppose it's >possible that noone's noticed this. (Or that nobody cares?) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I assume you mean :-) here. > >I will explain what to do to get this "bug" to appear. (BTW, don't worry-- >there's no danger of crashing; this is just a visual thing.) < description of problem omitted > > >What I want to know is: WHY???? I figure it must be something related to >the LayerInfo structure for the screen, since it applies to ALL >smart_refresh layers on the screen. Why does sizing a layer get rid of the >problem, while adding/deleting new layers does not??? Because the size of the layer changed, therefore the amount of space covered by more than 1 layer decreased allowing the routines to remove more unused cliprects. > >SUGGESTION: Whatever piece of code in SizeLayer() that fixes the problem >should be duplicated and stuck in MoveLayer(). :-) ha >If someone could tell me why this happens and how to fix it, I'd be happy to >write a little patch that SetFunction()'s MoveLayer(). (A temporary patch -- The proper solution to the problem is entirely more complex then what you propose. SetFunction MoveLayer won't help as you stated above since the same problem occurs when creating/deleting layers. >I would think this could be fixed in 1.4?!?!!) A new redicing algorithm is already in V1.4. You alpha testers out there should notice some difference. Unfortunately one of the side affects of the new routine is a transient need for more memory than any previous release of the layer library. > >Bill W. Kelly >{nosc ucsd hplabs!hp-sdd}!crash!pnet01!billk crash!pnet01!billk@nosc.mil > billk@pnet01.cts.com -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale