Dragging the imagetool image palette window with mouse shift-left over the main imagetool window can leave areas of the main window temporarily cyan-colored. These areas are quickly repaired, but persist long enough to be noticed. The effect is particularly pronounced when the window being dragged is partially inside and partially outside the imagetool main window. These effects occur because the imagetool main window is an Xview WIN_TRANSPARENT window. This means the background of the corresponding X window is set to None. For this type of window, the server relies on the application to repair damaged areas after an occluding window is moved. This method of damage repair is inherently slow because the client must process damage events and send rendering requests.
The imagetool image palette window is an 8-bit window. The pixel data resides in the Creator accelerator 8-bit red channel. The background pixel value of this 8-bit window is a small number, typically 0x02. The data in the red channel doesn't damage data in the green and blue channels. The background of the main window was white (0xffffff) but when the 8-bit window occludes, the pixel values are 0xffff02.
When the 8-bit window occludes the area, it is viewed as an 8-bit window. But when the 8-bit window is moved, the server immediately changes the window ID values in this region, indicating that the region is now to be viewed as a 24-bit window. This happens before the background is repaired. So, for a moment, the old pixel values in this region (0xffff02) are viewed as a 24-bit pixel. This pixel value is viewed as pure blue + pure green, which forms cyan.
This effect can also be seen on the SX frame buffer, although the SX frame buffer stores its 8-bit windows in the blue channel, so the transient color is green + red, which appears as yellow.
This effect is not as noticeable on the SX frame buffer, because it is more difficult to detect a contrast difference between yellow and white. On the Creator accelerator however, the difference between cyan and white is more pronounced. The effect also takes longer to go away when the dragged window is partially outside the imagetool window. This occurs because the Creator hardware has more rendering state to maintain than the SX frame buffer; dragging outside the imagetool window causes the window manager to continuously update the imagetool window header. This causes text rendering operations to be interleaved with copy operations. And since both operations use different rendering state, the state must be continually loaded and reloaded into the Creator hardware context. Thus, the repair of the transient color regions in on Creator in this situation is slower than the SX.
This example has dealt specifically with imagetool, but this will happen with any X window whose background is set to None. A bug for this has been filed for imagetool (Bug id 1215303).
To summarize, transient color effects like the one described above will occur on any window that has Background set to None. Applications that use this type of window should use some another background mode to avoid these effects. The X server can then repair the damage soon after it occurs.