Thanks for the suggestion. I tried it. Hard to tell whether or not there is a significant performance increase. There might be but it is relatively small (probably because the "red square" area takes up about half of the screen's real estate).
Either case, even with this perf. improvement, the motion updates are noticeably slow (when compared to the "canvas0" approach). I'll stick with "canvas0" for now, hopefully there is some way to detect the "screensaver event".
That could be the difference. If the "red square" takes up half the screen, then it may need to be sliced up, too, otherwise you're incurring some of the same penalty of drawing a large swatch in a single layer.
I also used that method for redrawing smaller parts of the screen (ex. listbox selection background, individual poster art, blocks of text, etc), and saw increases from as much as 2 seconds down to 500ms, so it may just not be as effective for larger portions of the screen. Maybe a combination of the two methods would produce better results.
Detecting the screensaver will actually require writing data to a common area, and checking that periodically. It's not pretty, and there will be a delay on return from screensaver, but it's possible. The audio player sample in the SDK does something similar in order to share data between the main app and the screensaver, so there may be something there you can leverage.
It's also important to note that the issue isn't limited to the screensaver. Anything you draw on top of the "canvas0" will leave an artifact unless you redraw it.
I'm sure you've already seen them, but we've had a few good conversation about roImageCanvas performance awhile back: