guineau@wjg.enet.dec.com (W. John Guineau) (01/22/91)
In article <17628@cbmvax.commodore.com>, spence@cbmvax.commodore.com (Spencer Shanson) writes: |> |> In article <18901@shlump.nac.dec.com> guineau@wjg.enet.dec.com (W. |> John Guineau) writes: |> > |> >I know there is a bug in the layers.library stuff that causes |> things |> >to get real slow when you have lots of windows/movement/sizing. |> > |> >I have 2 questions: |> > |> > 1. Could someone give me a better description of exactly what |> > and where the bug is? |> This isn't so much a bug, more a side-effect of allowing overlapping |> windows. |> The more windows you have overalapping, the mor cliprects need to be |> built |> and maintained. ClipRects are the 'sleight of hand' the OS uses to |> maintain |> hidden and overlapping pieces of windows. The more you have, the more |> work |> needs to be done. This is especially true when moving and resizing as |> new |> cliprects need to be built, old ones coalesced (to optimise) and |> hidden parts |> redrawn. We are aware of the speed hit with large numbers of windows, |> and |> are currently looking into the problem. So this effect is still in 2.0? Has it been alleviated at all? |> > |> > 2. Is there a workaround (other than WB 2.0 or not using lots |> > of windows!) |> > |> If this really is a problem for you, try to avoid overlapping your windows |> so much. Apart from that, you could either buy a faster machine, or wait |> until we have fixed the problem here. Sorry :-( Gee, I already have a 28mhz 68030 and lots of ram (7 meg)... Seriously, I appreciate the info. Hopefully 2.0 will look so nice that this layers feature will not be so apparent :-) |> -- |> --------------------------------------------------------------------------- |> Spencer Shanson - Amiga Software Engineer | email: spence@commodore.COM |> | or uunet!cbmvax!spence |> All opinions expressed are my own, and do not | "A picture is worth 1000 |> (necessarily) represent those of Commodore. | words, or about 300,000 |> | bytes." |> -- W. John Guineau grep meaning life | more Digital Equipment Corporation guineau@wjg.enet.dec.com or wjg@wpi.wpi.edu
spence@cbmvax.commodore.com (Spencer Shanson) (01/22/91)
In article <19236@shlump.nac.dec.com> guineau@wjg.enet.dec.com writes: > [stuff deleted] >So this effect is still in 2.0? Has it been alleviated at all? The problem will be alleviated before the final 2.0 release. > > >|> > >|> > 2. Is there a workaround (other than WB 2.0 or not using lots >|> > of windows!) >|> > >|> If this really is a problem for you, try to avoid overlapping your windows >|> so much. Apart from that, you could either buy a faster machine, or wait >|> until we have fixed the problem here. Sorry :-( In addition, are the windows concerned windows of your own program? If so, then you should take a look at the documentation concerning BeginRefresh() and EndRefresh() in the RKMs. You may find them useful in trying to speed up refreshing -- --------------------------------------------------------------------------- Spencer Shanson - Amiga Software Engineer | email: spence@commodore.COM | or uunet!cbmvax!spence All opinions expressed are my own, and do not | "A picture is worth 1000 (necessarily) represent those of Commodore. | words, or about 300,000 | bytes."
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) (01/23/91)
[Could someone add this to the monthly posting?] Yes, Layers has been improved in AmigaDOS 2.0. Why does it get progressively slower in pre-2.0? As you move windows around, the "behind" windows get sliced and diced. The problem is that smaller bits are never de-diced. Well, they are, but not as much as they could be. 2.0 has a much better de-dicing routine. How to help the situation? (1) Don't move windows (sometimes you can do this). *or* (2) re-size the window to be as small as possible, release the re-size gadget; now re-size it to the size you want. This clears out all the dices on the "expanded portion" of the window. Ta da. Tom -- Headers, headers everywhere! Who needs a .sig?
jap@convex.cl.msu.edu (Joe Porkka) (01/23/91)
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) writes: >[Could someone add this to the monthly posting?] >Yes, Layers has been improved in AmigaDOS 2.0. >Why does it get progressively slower in pre-2.0? As you move windows Um, still does get slower in 2.0. The dedicer may be better, but Layers handling of lots of windows (10 or more) is still poor. Things get REAL slow if you open 20 or more windows, then try to move one.
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) (01/24/91)
In article <1991Jan22.204914.7652@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >> [ Is layers faster in 2.0? ] > Um, still does get slower in 2.0. > > The dedicer may be better, but Layers handling of lots of windows > (10 or more) is still poor. Things get REAL slow if you > open 20 or more windows, then try to move one. Someone from C-A has stated that layers will be faster in the final (ROM) release of 2.0 but it isn't faster now. Thinking back, someone (non C-A) once explained why layers would still be slow after the de-dicing is improved. [Recollection mode ON] Layers is based on a paper presented at SIGGRAPH a couple years ago. I'm sure I could get the exact bibliographic reference if someone asked for it. Basically, the pseudo-code presented in the paper was almost directly translated into C (or BCPL?) to create layers.library. This included the sequential searches used all over the code. So, it seems that the layers could be stored in sorted order and faster searches could be implemented. [Recollection mode OFF] Could anyone from C-A tell me how good my memory is? Tom -- Headers, headers everywhere! Who needs a .sig?
jap@convex.cl.msu.edu (Joe Porkka) (01/25/91)
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) writes: >In article <1991Jan22.204914.7652@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >>> [ Is layers faster in 2.0? ] >> Um, still does get slower in 2.0. >> >> The dedicer may be better, but Layers handling of lots of windows >> (10 or more) is still poor. Things get REAL slow if you >> open 20 or more windows, then try to move one. >Someone from C-A has stated that layers will be faster in the final >(ROM) release of 2.0 but it isn't faster now. >Thinking back, someone (non C-A) once explained why layers would still >be slow after the de-dicing is improved. Someone on BIX (in the CBM clan) posting a query to the effect "Does anybody muck with the internals of ClipRects" If not, there there is a dandy way to speed thing up a bunch. This was probly less than a month ago - so I dunno if such a change could possibly make it into a 2.x release, which is supposed to be RSN. >[Recollection mode ON] >Layers is based on a paper presented at SIGGRAPH a couple years ago. Yes, but more than a couple years ago :-) Gotta be before '85.
rsbx@cbmvax.commodore.com (Raymond S. Brand) (01/26/91)
In article <1991Jan25.003716.19167@msuinfo.cl.msu.edu>, jap@convex.cl.msu.edu (Joe Porkka) writes: > limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) writes: > > >In article <1991Jan22.204914.7652@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: > > >Layers is based on a paper presented at SIGGRAPH a couple years ago. > > Yes, but more than a couple years ago :-) Gotta be before '85. The layers.library is based on a paper by Rob Pike of Bell Labs titled "Graphics in Overlapping Bitmap Layers" published in ACM Transactions on Graphics, Vol. 2, No. 2, April 1983, Pages 135-160; and possibly Computer Graphics (SigGraph) as well. It's a very interesting paper but ignores some important issues. rsbx ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "Looking" ------------------------------------------------------------------------
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/28/91)
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) writes:
[Recollection mode ON]
Layers is based on a paper presented at SIGGRAPH a couple years ago.
I'm sure I could get the exact bibliographic reference if someone
asked for it. Basically, the pseudo-code presented in the paper was
almost directly translated into C (or BCPL?) to create layers.library.
This included the sequential searches used all over the code. So, it
seems that the layers could be stored in sorted order and faster
searches could be implemented.
[Recollection mode OFF]
Well, not "sorted"; overlapping 2D objects don't sort well.
However, there are some very clever tree structures for storing quick
access to recursive 2D subdivisions of a rectangle parallel to the axes;
take a look at Hannan Samet's textbook Applications of Spacial Data
Structures, an exhaustive study of fast storage and retrieval and
indexing methods for objects with dimensions and metrics, like a
windowed raster screen.
Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>