Caching is now implemented for a gadget’s visible rectangles. Instead of reconstructing a vector of visible regions every time a gadget wants to draw itself, it only rebuilds the vector if something has happened to invalidate the vector. This could be another gadget higher up the z-order moving, opening, closing, depth-swapping, resizing, etc, or it could be that the gadget itself has moved/resized/whatever.
This paves the way for the GraphicsPort object - each drawing function can use the pre-cached clipping data. It also seems to have made Woopsi a tiny bit faster, and has led to the creation of the absurdly-named “invalidateLowerGadgetsVisibleRectCache()” function. This deserves special mention as the most ridiculous function name I’ve ever come up with, but it is at least descriptive.
Fixed a few problems with the setBorderless() function in the Screen and Window class - they weren’t checking to see if the _activeGadget and _clickedGadget pointers were pointing at the border gadgets before deleting them. I’ve moved all of the code to completely delete a gadget into a new “removeGadget” function, which does handy things like checking those two pointers and whether or not the gadget is a decoration (manipulates the _decorationCount value as necessary).
One problem I’ve found is that adding an instance of the Alert class to a screen increases the decoration count in another screen. This makes no sense, so I suspect a memory leak. As the Alert isn’t even vaguely finished yet, I’m not too concerned.
Another development that I should include - a “_requiresRedraw” variable that can be set to “true” when something has occurred that will require the gadget to redraw. This isn’t the same thing as the cache invalidation - that should only be called when the layout of the screen changes. Requiring a redraw can happen when a SuperBitmap’s buffer changes, for example, or a button is clicked. One of the problems with Woopsi at the moment is that all drawing is done immediately, so if I click a button that click is drawn instantly to the screen. However, if I’m flipping a screen from one display to the other, I don’t particularly want the button to be redrawn before the display has flipped. Deferring the draw by using the “_requiresRedraw” variable and calling each gadget’s “draw()” function every VBL would solve the problem and probably make things faster again.