Redraw Stores

Redraw segments and non-redraw handling

When the Window Server receives a batch of redraw drawing, everything between a BeginRedraw/EndRedraw bracket is stored in a single redraw segment . The segment is marked as ESegmentTypePendingRedraw while it is being received, and ESegmentTypeRedraw once it is complete.

Redraw segments have a region to which they apply. For ESegmentTypeRedraw , the region is initially set to be the rectangle passed into the BeginRedraw() call. When a new ESegmentTypeRedraw is created, its region is subtracted from the regions of all existing segments. This reflects the fact that redraw drawing replaces existing drawing. If, as a consequence of new redraw drawing, the region of an existing segment becomes empty, that segment is discarded. Its drawing has been replaced everywhere, so it is no longer needed.

What happens to drawing that is received between an EndRedraw and the next BeginRedraw —and which is therefore non-redraw drawing —depends on which variant is in use:

• In ScreenPlay, non-redraw drawing is not stored in a segment but instead triggers the Window Server to invalidate the entire window. This means that the client application must then perform a full window redraw.

• In the non-ScreenPlay variant, non-redraw drawing is stored in a segment marked as ESegmentTypeNonRedraw . For these segments the region is initially set to be the whole window and does not affect the regions of existing segments, because non-redraw drawing is drawn over existing drawing.

Redraw store playback

When playback is required, the redraw store goes through the redraw segments and replays them if the region for the segment intersects the region that is to be redrawn. It follows from the way that they are managed that the regions of redraw segments are mutually disjoint. This means that in ScreenPlay they can be replayed in any order. This is also true in the non-ScreenPlay when there are only redraw segments present.

In the non-ScreenPlay variant, any non-redraw segments are replayed in earliest-first order, because they draw on top of earlier drawing.

Aging of non-redraw segments

Variant : Non-ScreenPlay only.

Non-redraw segments can cause inefficient operation of redraw stores. For this reason, in the non-ScreenPlay variant where non-redraw segments are still used, the Window Server "ages" them. That is, non-redraw segments are considered to have a finite lifetime, after which they are discarded. When a non-redraw segment is discarded, the Window Server makes a redraw request to the client asking it to provide new draw operations for the invalid region.

The lifetime for non-redraw segments is set in the WSINI.INI file using the parameter NONREDRAWAGELIMIT , followed by a duration in microseconds. If this line is not present in the WSINI.INI , a default of one second is used.

Atomic Redraws

Variant : Both (ScreenPlay and non-ScreenPlay).

Another WSINI.INI file setting that affects redraw storing is ATOMICREDRAWS . If this parameter is present, new draw operations received after a BeginRedraw() are not considered valid until the corresponding EndRedraw() is received. In particular, a new segment does not replace existing segments until it is complete. This has the consequence that if redraw store playback is required before the EndRedraw() for a new segment is received, draw operations from old segments for that region are used instead. Thus drawing within Begin/EndRedraw brackets can be considered as an atomic operation. This eliminates one potential source of flicker.