Redraw store in window server

S60 5th Edition enables the redraw store in window feature.

Enabling redraw

Window Server features are configured in the file z:\system\data\wsini.ini. By default, the redraw store feature is enabled but it can also be disabled by defining the NOREDRAWSTORING keyword in wsini.ini.

Also, some other features, such as TRANSPARENCY, automatically enable also the redraw store feature even if NOREDRAWSTORING is defined.

Impacts to applications

Without the redraw store feature, all screen updates always result in the Window Server requesting the application to redraw all windows that are displayed in the screen area. In a normal situation, this ultimately means that the virtual method CCoeControl::Draw is called for those UI controls that reside in the screen area to be redrawn.

In this case, the applications can trust that CCoeControl::Draw is always called again when there is a screen update.

The situation is different when the redraw store feature is enabled. In this case, Window Server requests the drawing commands only once per window (CCoeControl::Draw gets called), after which it stores the primitive drawing commands in the server side. When the screen needs to be updated the next time - and it is not initiated by a call to CCoeControl::Draw or invalidating a window - the window server directly uses the drawing commands stored for particular windows in order to redraw the required area.

The application or UI control code can also initiate a redraw by either invalidating the window or by calling CCoeControl::Draw. In this case the drawing commands that have possibly earlier been stored in the window server’s redraw store for that particular window are discarded and replaced with the commands that the CCoeControl::Draw issues when called again.

Examples of common situations, which may result in the screen not being automatically updated in the existing applications are the following:

  • The application shows a pop-up and assumes that CCoeControl::Draw is called for the UI controls below the pop-up once the pop-up has been dismissed.

  • The application assumes that when it is brought to the foreground after having been in the background, CCoeControl::Draw is called for the UI controls and any changes in the screen contents are automatically updated.

In these kinds of cases, when the redraw store is enabled the application code should explicitly handle any changes in the screen contents by calling CCoeControl::Draw for those UI controls whose contents may have been changed.

As a side note, view switches inside an application usually work OK, assuming that the views are created on activation and destroyed on deactivation. In this case, the window(s) of the view do not exist when the view is not visible and the redraw store does not have any commands stored for that view.