Conference hydra::amiga_v1

Ken, what are you using now?  I thought that Intuition is supposed to handle
all that clipping automatically - naturally there may be bugs.  I've had
good luck with window operations, even when drawing outside the "borders".

Typically, I have created a window with SMART_REFRESH | GIMMEZEROZERO.
After opening the window, I create an "off screen" rastport which actually
receives the graphic operations.  Then a BltBitMapRastPort operation
is used to copy the "off screen" bitmap into the window's "visible" rast port.

This is for a simple double-buffering scheme.  It's not necessary for most
tasks.  Direct window operations seem to work ok.

Steve

    Steve,
    
    Aha, the old GIMMEZEROZERO flag! I wasn't sure from the docs whether
    that did the auto-clipping or not; also, what about side-effects?
    Besides apparently providing auto-clipping, what else does it do? I've 
    never used it because I wasn't sure what else it did.
    
    I hate to say it, but i'm manually 'clipping' - by checking coords
    before I put anything to the window.
    
    I would like, however, to move into the twentieth century!
    
    Ken

    
    
    	In a nutshell, You can't. Amigados doesn't Clip. You might get
    away with writing into a super bitmap and displaying part of it, but
    the super bitmap is limited to 1024 x 1024. If you miss the super
    bitmap you GURU.
    
    		Steve P.
    

I think Steve Peters is right.  I just pulled out my old RKM and it states:

"Caution: If you attempt to draw a line outside the bounds of the BitMap, using
the basic initialized RastPort, you may possibly crash the system.  You must
either do your own software clipping to assure the line is in range, or use
the layer library."

I don't have any Layers library info around, but it's a (to paraphrase Peck)
layer that is build on top of the graphics system and provides routines 
for splitting a common drawing area into multiple layers. The Layers 
library containes routines for creating, deleting, moving layers as well 
as managing priority, and manipulating the contents of the layers. 
See Chapter 5 of Mortimore's "Amiga Programmer's Handbook", vol 1.

Peck's book also states "Setting the GIMMEZEROZERO flag means that the drawing
area is created so that the coordinate location is in the upper left corner
of the area inside the window border (0,0).  It also means that all drawing
is clipped (cut off) within the borders of the window."

This seems to imply that clipping is done automatically, but what I think
it really means is that you won't draw over the window borders.  Try it and
see what happens.

Hope some of this helps,

Steve   

	Two points:

	GIMMEZEROZERO windows do their own clipping, at the cost of
	speed.  They create a separate Layer (and bitmap) for the
	border of the window.

	If you want to speed things up a little, or if you need more
	flexibility, you can create your own Layer and associate it
	with the bitmap for your drawing (either a window or just a
	plain old bitmap).  Once the Layer is active, drawing operations
	will be restricted to any clipping regions you open in the Layer.
	There exist a number of functions for specifying the shape and
	size of the clipping regions.

	I don't have all the details in my head, but I just finished
	writing an Xlib-like interface to the Amiga drawing routines
	(including PixMaps), so I know it works.  I can supply more
	details if you're interested, but you might start by looking
	at the Layers chapter in the RKM.

	Art

    re: .5
    
    It suddenly occurred to me that there are actually two meanings to the
    term 'clipping' -
    
    1. clipping drawing/text outside the MAXIMUM bounds of a window
    2. clipping drawing/text outside the CURRENT bounds of a window - the
    window may be re-sized and moved.
    
    I assume that clipping#2 is ALWAYS done by intuition, regardless of
    how you've defined your windows.
    
    It's clipping#1 that I'm interested in, and that I presume the Layers
    stuff (which I will look into in my RKM and assoc. books) will handle.
    
    Right?
    
    Ken

re: .6

>    1. clipping drawing/text outside the MAXIMUM bounds of a window
>    2. clipping drawing/text outside the CURRENT bounds of a window - the
>    window may be re-sized and moved.

	Intuition itself ALWAYS handles situation #2 for you by using
	the Layers library.  You only need to worry about situation #1
	(which is just another way of saying, "Don't draw beyond the 
	limits of a bit-map, or Bad Things will happen").

	Perhaps obviously, if the window is at its maximum size, #1 and
	#2 become the same situation...

	You have two ways to handle situation #1:

	-declare the window GIMMEZEROZERO

	-use the Layers library calls to:
		+ allocate a region (NewRegion())
		+ set up the clipping area within this region
		+ install the region on the window using InstallClipRect()
		+ do some drawing... all drawing and text functions will
		  limit their activity to drawable area of the region.
		+ BEFORE YOU DESTROY THE WINDOW, use InstallClipRect() again
		  to de-install the region
		+ deallocate the region (DisposeRegion())

	Be aware that you can perform logical operations on regions to 
	get more complex clipping-area shapes -- you're still limited
	to rectangles, however.

	The Layers functions can also be used to set up bit-maps which
	have no corresponding windows; this allows you to do off-screen
	drawing, then use ClipBlit to copy it to a window (or vice-versa,
	if you want to do cut-and-paste type things).  This is a little
	trickier, but not terrible.

	-Art

    re: .7
    
    is there any reason why option 1, simply declaring the window
    GIMMEZEROZERO, is not the option of choice? It's sounds a h*lluva
    lot simpler than option 2, and will therefore result in much cleaner
    and more maintainable code.
    
    thanks for your clean and maintainable reply!
    
    ken

re: .8 
    
>    is there any reason why option 1, simply declaring the window
>    GIMMEZEROZERO, is not the option of choice? It's sounds a h*lluva

	The only thing about GZZ windows is that they use a lot more
	memory.  In addition to doing the Layers stuff for you in a
	GZZ window, Intuition also allocates a whole separate bitmap
	just for the window border/title bar -- so, in reality, it
	costs you as much CHIP memory as two non-GZZ windows.  On 
	smaller machines, that can be a drain on resources.

	They also tend to be a little slower, but that's the cost of
	the Layers stuff, so you'd be paying that if you did your own
	Layers...

	But yeah, from a programming standpoint, it's a much easier
	solution to implement.

	-Art

Re: .*

I could be wrong here, but I don't think that if all you want to do is
clip your graphics to your window that you need to do anything special.

Intuition always sets up a clip regions for its windows.  The graphics
routines will ignore any calls that attempt to draw outside of the
current size of the window (the current size of the window is, by definition,
less than or equal to the maximum size of the window).

The warnings in the graphics section of the ROM Kernal manuals that say
to either install a clip region or make sure that you don't draw outside
of your bitmap only apply if you set up your own rast port.  Part of
Intuition's job in opening windows is to supply clip regions for them.

GZZ windows aren't necessary just to get clipping at you window boundary.
The advantages of GZZ windows are:

	1.  The coordinate system for the drawing area starts at 0,0.
	    In normal windows, the coordinate system beings 0,0 at the
	    top, left pixel in the border of the window.  To get to the
	    drawing area, you have to offset your coordinates by the
	    height of the title bar or top border and by the left border.
	    (There are members in the Window data structure that provide
	    these values for your use.)

	2.  GZZ windows prevent you from scribbling over the window borders
	    and title bar.  This is a particularly bad problem if you have
	    lots of gadgets in a resizeable window.  If you use a GZZ window,
	    Intuition will only let gadgets with the border flag draw over
	    a border, and the gadgets without the border flag have their
	    rendering confined to the drawing area between the borders.