Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!caip!ut-sally!pyramid!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: net.micro.amiga
Subject: Re: ---Bug Report--- (backdrops)
Message-ID: <1326@amiga.amiga.UUCP>
Date: Sat, 21-Jun-86 19:03:56 EDT
Article-I.D.: amiga.1326
Posted: Sat Jun 21 19:03:56 1986
Date-Received: Mon, 23-Jun-86 03:42:43 EDT
References: <675@Navajo.ARPA> <432@cbmvax.cbmvax.cbm.UUCP>
Reply-To: jimm@homer.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
Lines: 79
Keywords: Backdrop, custom screen, screen gadgets, string gadgets

In article <432@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes:
>In article <675@Navajo.ARPA> rokicki@Navajo.ARPA (Tomas Rokicki) writes:
>>Scenerio:  I have a custom 640x400 one-bit-deep screen, with a full
>>640x400 backdrop window with no borders.  I have attached several
>>gadgets to the screen (Boolean and string gadgets) . . .
>
>Dear Tom:
>
>	I hate to disappoint you, but Screen gadgets do NOT WORK, period,
>and support for them has basically been removed in 1.2 (correct me if I'm
>wrong Jim M).
>	Yes, you'll have to stick them on the backdrop window instead.

That's right.

>Moral: ignore the Intuition manual's mentions of attaching gadgets to screens.

That's a good idea, but I wouldn't call it the Moral.

>Question though: doesn't it peeve you that Intuition needs a rastport for
>the screen (32K for interlace 1 bit plane - CHOMP) and then another 32K and
>change for the backdrop window!  Seems like a waste.  I probably don't
>understand all the implications, but I think if the screen were treated like
>a Layer on a view, backdrop windows would be unecessary, because SMART_REFRESH
>would handle all the overlapping of things.
>

Bull Cookies!!

A RastPort is 100 bytes.  The screen Raster (*RastPort->BitMap->Planes[i])
is indeed 32000 bytes (for 640x400).  The amount of memory for a backdrop
window (beyond window and layer overhead and the 100 byte RastPort) is 
determined by its refresh type.

Simple Refresh -- No, never, none "pixel" bits get allocated no matter what.
    Such a backdrop window is typically used for input and gadgets.

Smart Refresh -- the obscured portion of your backdrop window is saved
    offscreen in a chain of little bitmaps whose net pixel total reaches
    the area of the entire window (could be 32000) when the entire window
    is obscured.  Lots of windows dicing up the screen can cause a great number
    of bitmaps to be used, which can imply a considerable amount of memory
    overhead in that chain of bitmaps (actually called ClipRects).

    The reason you might tolerate this is to benefit from the automatic
    redrawing of the contents of the backdrop window when obscured portions
    are exposed (window changes or requesters).  Good, if you have backdrop
    rendering that is time consuming to reproduce.

Super Bitmap -- Only in this case is a 32000 byte off-screen buffer required.
    This is rarely required for a backdrop window.


Full Screen applications can try the following (which in 1.2 can be applied
more sanely to the area of the title bar).

    open a custom bit map screen. (use SCREENQUIET in 1.2)

    open a full screen backdrop smart refresh window.

    you can now render into your screen's rastport a couple of ways:
	1- render through the window's rastport, which incurs (trivial)
	  clipping overhead.  useful if you need clipping done
	2- render through the screen's rastport.  this is absolutely fast
	  (benefits from hardware-assist linedraw, blitter, etc.) and
	  incurs no clipping overhead.
	3- turn them bits on and off by yerself (i.e., modify the values
	  in the custom bit map).  Good for Intro. to Graphics 101
	  students, paint programs, Freemap, digitizers, cheapo ports
	  from IBM PC's, and ???.

    the nice part is that if you want to put up a requester or some window
    (like a control panel or pallette) you just cease methods 2 and 3, and
    your imaging done with these "low-level" methods is saved and restored
    just as you would expect the rendering done by method 1 into a smart
    refresh window to be.

Hope this is interesting.
				jimm