The coord cache is filled in the drawing phase (the metrics phase fills the size part of the coord cache only). We _do_ have a 'null painter' which only fills the cache, but if we did metrics + null painter painting + real painting in every case, drawing might get slow. Just a suspicion, though.
An idea to fix the update over ADSL in a general way, in a way which does not require the kernel to know about the extend a change has on the screen:
The null painting phase can be used to detect what really needs to be updated.
During an update, we built a fingerprint hash of each painting operation: a hash based on the content and the operation itself. This finger-print is stored in a data-structure indexed by the rectangle the operation covers.
So, each update results in a set of fingerprints, which exactly describe what was drawn at each pixel on the screen: All pixels in the affected rectangle has that hash associated.
Now we need to update the screen, because something changed. First, we draw with the null-painter. For each operation, we also calculate the fingerprint and rectangles like above.
So, now we have two data-structures of rectangles with their associated fingerprints. We compare the old and the new entires. All the different entries tell us what really needs to be updated. Thus, we build a set of rectangles which tell us what parts of the screen really needs an update.
Then we fill these parts of the screen with the background color.
Next, we start the second drawing phase with a real painter: For all requests, we check whether we intersect a rectangle which needs an update. If not, we just skip it. If we do, we do the drawing as requested.
Regards, Asger
