Clearing a window under AmigaOS

[Wrangler]

A real noob question but what is the easiest (and quickest if that is different) to clear a window under AmigaOS?

Situation is that I've opened a window with OpenWindowTags, which includes some gadgets. I've used the window and now I want to clear the contents.

SetRast(win->RPort,0);

clears the window contents and the gadgets but I want to preserve them

I can't find a command like:

ClearWindow(win);

[hooverphonique]

Easiest is probably to clear the bitmap contents (e.g. with SetRast), then refresh/redraw the gadgets - intuition/gadtools has functions for this.

[Wrangler]

That works, but only up a point - the gadgets are refreshed but not the window borders. Anyway to refresh them too?

(I'm only using system gadgets and RefreshGadgets)

[No.3]

RectFill is your friend.

[Wrangler]

Awesome, that does it!

[Thomas Richter]

Originally Posted by Wrangler

A real noob question but what is the easiest (and quickest if that is different) to clear a window under AmigaOS?

You find the border sizes in the window structure, and you also find the window size there. So subtract border sizes from the window to get the dimension of the rectangle to fill, and add the size of the top and left border. Then perform a RectFill().


Alternatively, use a GIMMEZEROZERO window, and then the interior of the window has a separate layer, and you can use SetRast.


Yet alternatively, install a cliprect to the window rast port that clips to the interior window area, then use SetRast.

[Olaf Barthel]

Originally Posted by Thomas Richter

Alternatively, use a GIMMEZEROZERO window, and then the interior of the window has a separate layer, and you can use SetRast.

I reckon that this aspect is what gave this feature its name. The operating system documentation always states its name, but never how it got its name.

By default the window border elements and the portion inside the border share the same rendering surface (the Window->RastPort). Which means that you need your own code to watch where it plays and what it is permitted to paint over.

You need to offset your rendering origin by the size of the left and top borders, and the size of the rendering area is also reduced by the size of the right and bottom borders. This means that the rendering origin coordinates are no longer at (0, 0) but might be a (10, 5), for example.

If you request a GIMMEZEROZERO window, rendering into Window->RastPort always starts at the (0, 0) origin (literally zero zero) and its area you render into is always clipped so that it never overwrites the window border area.

There are plenty of reasons to use an alternative to the GIMMEZEROZERO option because it makes rendering inside Intuition a lot more complex than it has any right to. The 3rd edition "RKM Libraries" even covers the many options you have if you do not want to use a GIMMEZEROZERO window.

[aros-sg]

Originally Posted by Thomas Richter

Yet alternatively, install a cliprect to the window rast port that clips to the interior window area, then use SetRast.

Only AROS can do that (*). Everything else can only install clipregion into layer, not rastport as well. And even if you do that you usually have the problem of async Intutition window resizing so you still can end up rendering into window border and then need to refresh the window frame to make sure that the "trash" is repaired.

For the origin thing one can (ab)use layer's Scroll_x, Scroll_y.

(*) Can install one additional cliprect (not region) into rastport where right/bottom of the cliprect can be relative to the layer size.

[Thomas Richter]

Originally Posted by aros-sg

Only AROS can do that (*).

No, that's really one of the easiest exercises in graphics and layers. I really wonder why GZZ windows are realized in such a complicated way, they even create a lot more overhead when moving - after all two layers have to be moved.

[aros-sg]

Originally Posted by Thomas Richter

No, ...

So you added this? RPTAG_DrawBounds? In standard/old AOS 3.1 it's a get-only attribute.

I really wonder why GZZ windows are realized in such a complicated way.

Yes, can be done with one additional AndRectRect() and some coordinate shifting when traversing cliprects.

[Thomas Richter]

Originally Posted by aros-sg

So you added this? RPTAG_DrawBounds? In standard/old AOS 3.1 it's a get-only attribute.

There is absolutely nothing to add. Everything you need for this functionality is already there. Create a new region, add a rectangle that describes the inner area of the window, or the region to the rectangle, then call InstallClipRegion(), then adjust the scroll offset of the window rastport. There is nothing "new" required.

Originally Posted by aros-sg

Yes, can be done with one additional AndRectRect() and some coordinate shifting when traversing cliprects.

Again, all the functionality to clip to window internals is already there, and it works perfectly fine with the existing intuition system.

[Thomas Richter]

Here is a little bit of code how to do that. To make things a little bit more entertaining, it is this time in Pascal. The WindowInfo structure is something internal in this little project, just disregard, it is only for housekeeping.

PROCEDURE InstallOffset(w : WindowPtr; x,y : SHORT);
VAR
        winfo   :       WindowInfoPtr;
BEGIN
        winfo:=InfoOf_W(w);

        WITH w^.WLayer^ DO BEGIN
                Scroll_X:=-x;
                Scroll_Y:=-y;
        END;
        WITH winfo^ DO BEGIN
                Offset_X:=x;
                Offset_Y:=y;
        END;
END;

PROCEDURE InstallClip(w : WindowPtr; x1,y1,x2,y2 : SHORT);
VAR
        region  :       RegionPtr;
        winfo   :       WindowInfoPtr;
BEGIN

        winfo:=InfoOf_W(w);
        region:=NewRegion();
        IF region=NIL THEN
                failexit("Unable to create new clip region");

        SortCoords(x1,y1,x2,y2);
        WITH rectptr^ DO BEGIN
                MinX:=x1;
                MinY:=y1;
                MaxX:=x2;
                MaxY:=y2;
        END;

        IF NOT OrRectRegion(region,rectptr) THEN
                failexit("Unable to create clip recangle");

        winfo^.ClipRegion:=region;
        region:=InstallClipRegion(w^.WLayer,region);
        IF region<>NIL THEN
                DisposeRegion(region);

END;

PROCEDURE InstallStdClip(w : WindowPtr);
VAR
        xmin,ymin       :       SHORT;
        xmax,ymax       :       SHORT;
BEGIN
        Forbid;
        WITH w^ DO BEGIN
                xmin    :=      BorderLeft;
                ymin    :=      BorderTop;
                xmax    :=      Width-1-BorderRight;
                ymax    :=      Height-1-BorderBottom;
        END;
        Permit;

        InstallClip(w,xmin,ymin,xmax,ymax);
        InstallOffset(w,xmin,ymin);

END;

[aros-sg]

Originally Posted by Thomas Richter

all the functionality to clip to window internals is already there, and it works perfectly fine with the existing intuition system.

No, you cannot get 100 % gzz like behaviour with InstallClipRegion() alone, because of async resizing of windows, as said. Program can still end up rendering into window border, without further "hacks" like trying to prevent window size change during rendering with LockLayerInfo() which can cause other unwanted behaviour/side effects.


A clip region installed into a layer (not rastport as you said, that's why I said "only AROS can do that", where "that" is "installing a cliprect into a rastport") contains only cliprects with absolute coordinates, nothing relative to layer width/height which "only AROS can do" because in addition to the standard "install clipregion into layer" functionality has - as said - functionality to install additonal cliprect into a rastport where cliprect coordinates can be relative to layer width/height.