Window Map

At the moment, KolibriOS' graphics engine uses a 'flat' screen framebuffer which starts at ring0-accessible linear address LFB_BASE.

Each application can draw inside its own window using GUI sysfunctions; in most cases the co-ordinates relate to the client's area of the window. The kernel ignores any attempt to draw outside the window or to cross its borders.

One of the most important functions of the graphics subsistem is checking window's visibility status and blocking any drawing request related to overlapped (hidden) parts of the window. A special static system array, the _WinMap, is obviously used to detect the windows' visibility and overlapping.

_WinMap

_WinMap array is probably the simplest, fastest and resource-hungriest solution. It represents every pixel of the screen, and holds the window's TASK_ID byte for that pixel.

The array starts at [_WinMapAddress] and occupies [_WinMapSize] = (Ymax * Xmax) bytes.

Due to its very simple structure, dozens of GUI and window-related routines access _WinMap directly (that makes the code very compact, fast and hardly readable).

The array is CPU-cacheable. In one hand, it greatly accelerates most of GUI-related routines and services and explains the remarkable KolibriOS' graphics speed.

In the other hand, it seriously obstructs the Cache and can apparently slow down some time-critical processes and applications. That makes the _WinMap unsuitable for most of embedded applications.

_WinList

An essentially different approach has been tried in Kolibri-A branch.

_WinList is a list-chained set of dynamic lists that define screen positions of each non-overlapped rectangle on the screen. Such a structure

• dramatically reduces the size of window map;
• standardize all the map-related operations and moves them out of GUI procedures;
• accelerates rasterized graphics;
• reduces the code size.

(to be continued)