🚀 go-pugleaf

Pardon me if this has appeared before.  I have a rather large application
(30,000 lines or so of C) that does a lot of SIMPLE_REFRESH window opening,
closing, and movement.  This program's users interact with it constantly for
8-12 hours per day, and it is expensive to restart.  I have noticed that after
running this program for a while, it gets SO slow to move a window that overall
productivity dips significantly.

The problem seems to be the list of rectangles that is used to figure out
what is obscured and what is visible.  The list associated with the bottommost
window (a BACKDROP window, but that doesn't seem to matter) grows to a
tremendous size when windows are moved around, and makes window movement
very painful.  Examination of this list revealed just what I'd have expected
the underlying algorithm to produce, except that the rectangles are never
coalesced into the largest and fewest possible.  This appears to happen
most often for the bottommost window.  It seems to happen with SMART_REFRESH
windows too.

I am working on a 2500 running 1.3, though the problem appears on 2000s as
well.  I use Manx C, 3.6.  Has anybody else noticed this problem?  Is there
some documented or undocumented function to coalesce the rectangles?  I would
do it myself (kludge) but the data structures involved are not well documented
and I am afraid of breaking things even more.

Another problem I am having is that if the screen of my application is LACE
and I am using SIMPLE_REFRESH windows, occasionally the system software
involved in moving a window will spray junk into other CHIP ram areas,
including gadget image data and screen memory, BEFORE my program receives
a REFRESH message.  It's almost like the display code is starting to redraw
the screen before the Layers code is finished figuring out where such drawing
should be done.

If anybody recognizes and/or can help (or sympathize) with these problems,
please respond.  Thank you for your time.

derek