The problem described above is an
unavoidable consequence of using colour floods on the page in
question. When a window which obscures part of the page needs to be
hidden (This window could be tip help, a popup, a genie or even
another windows application) Windows will send a paint message to
Citect to tell it what part of the screen needs to be repainted.
The optimised drawing code will only redraw what it needs to except
when there are colour floods on the page. A colour flood will flood
a region with a given colour and stop when it reaches a boundary.
To demonstrate why the whole page is redrawn consider the
following example. A colour flood is positioned over an empty
rectangle. In runtime the empty rectangle is flooded red and the
page background colour is grey. Now consider what happens if a
popup is positioned over part of the flooded rectangle but the
location of the colour flood object is not obscured. Now when the
popup is hidden the obscured part of the rectangle is redrawn with
its inside painted in the page background colour of grey. The
remaining portion of the rectangle is painted red from the previous
colour flood. To avoid this problem it is necessary to redraw the
whole rectangle and redo the colour flood. This would be sufficient
for this simple case but often the colour flood boundary is not a
single object but a composite of many connected or overlapping
objects. This makes it virtually impossible to know the true
bounding rectangle for a colour flood so to guarantee the correct
repainting of a page with colour floods it is necessary to redraw
the entire page. The only way of avoiding this redrawing problem is
to avoid using colour floods on a page.
|