dale@amiga.UUCP (Dale Luck) (07/02/87)
<< The problem is that if you have a bunch of smart-refresh windows on the << screen, and do much window manipulation, they each get chopped up into a << whole bunch of super-small bitmaps and updating becomes pure agony. Simple << refresh is slightly (slightly! If you use a single Text() call for each << line of text you output, it's damn fast) slower for the simple case, but << its behaviour doesn't degrade nearly as badly. The number of Cliprects in a smart layer or simple refresh is the same. The difference is whether there is a bitmap allocated for the obscured cliprects. The unobscured cliprects bitmap pointer point to the shared bitmap. So the speed up you see is it just not writing into the nonexistent background buffers. <To toss an obvious idea out... how about a priority -200 task that coagulates/ <optimizes cliprects and frees the extra chip memory taken up by the above <situation? The Cliprects are coagulated after ever internal delete layer operation. MoveLayer and SizeLayer both use internal delete. This, besides delete layer is the only time it makes sense to try to combine obscured cliprects. The only thing that prevents completion of the dedicer is memory constraints. poof. If it cannot find the necessary amount of bits in the right size chunks it gives up and tries again the next time. Whenever any operation that affects the topography of the shared screen happens, it recalculates what it thinks is an optimal set of cliprects for that topography. Your lucky now, you should have seen it before I write the dedicer, If you had two windows up and just moved the window that was on top down 10 times in small increments, it just kept breaking those little cliprects up into smaller and more pieces. You don't see that now, so it must be doing something. Dale Luckm
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/02/87)
In article <> dale@amiga.UUCP (Dale Luck) typed: <In article <> bryce@cogsci.berkeley.EDU (Bryce Nesbitt) typed: << To toss an obvious idea out... how about a priority -200 task that coagulates << optimizes cliprects and frees the extra chip memory taken up by the above << situation? < < The Cliprects are coagulated after every internal delete layer operation. < MoveLayer and SizeLayer both use internal delete. [...] The only thing < that prevents completion of the dedicer is memory constraints. poof. > [If it can't find enough if gives up till next time...] I checked and that's right (of course it's right, he wrote the thing, silly). Other layer weirdness: Take a machine with only a CLI and do a <esc>[43m. (Background becomes red). Load sys:utilities/clock. Center the clock on the screen and push it behind the CLI. Press CTRL-L. Now resize the CLI just a bit. The area of the obscured clock window will "show through" for a moment. This behavior was what caused the asumption that there where dirty cliprects and/or fragmented bitmaps. (That and my defective expansion ram :-) Is there any hope for a future one step size and move layer? And (talking through my hat now) Poof() and UnPoof() which would move a layer totally off-screen yet still allow normal rendering to occur? (Also create the layer off-screen, prepare it, then present it to the world). (Besides the hack of hiding it behind a backdrop layer...)