Your experiment is an  interesting idea, but there are practical problems. For a start, did you use a high-level language or assembly code. If the latter, did you address the screen controller functions at the machine language level, or through system calls? Screen functions nowadays are very impressive, and system control functions are not bad, but at best the system calls  are like trying to instruct a boxer in the ring by telephone; by the time your sage advice gets through, his seconds will be carrying him out on a stretcher.

Using the screen's native capabilities by machine language controls can be many times faster than system calls. Also, if you are in fact coding for rotation of a three-segmented disk, your algorithm can be crucial. Brute force could be slow, whereas a bit of sneakiness in working out what pixels would change in every frame and changing only those, could speed things up by large factors.

Also, if your rotation of the screen was real rotation, that is a cumbersome process on a rasterised screen.

NB: I am not trying to teach you to suck eggs, irritating you  in case you happen to be an advanced programmer; just discussing aspects of the problem in the absence of face-to-face feedback!

You MIGHT get better effects if you avoid the complications of rotation by rather having linear change of a rectangular area with the colour changes moving from one side or top down. This would lend itself to far faster and simpler algorithms.

Of course, it also is possible that what you are asking is more than the screen physically can deliver, but to be sure of that you would have to explore some of the points that I mention.

Good luck,

Jon

You also might vary the difficulty of the task in various ways. For example you could use only two colours, say green and blue, and see whether you got a stable cyan, or cyan and red and see whether that gave white. Or you could double or quadruple  the number of segments, making them narrower, to increase the replacement rate. 

The colours available certainly do combine to give white of course; at least you can be certain of that. That is how the screen normally gives you white! :-)

Cheers,

Jon

I imagine your main problem stems from the screen refresh rate.

There would be a couple or three other things going on here.

First, your screen memory is written to with random access (I don't mean accidentally, I mean you can write to various areas of the image in any order you choose.) However it is read in synchronisation with the monitor scan, maybe 75 times a second, in top-to-bottom line order (It may even be interlaced to decrease flashing, i.e. take all the even rows on one scan and odd rows on the next.) So there is certainly going to be some frequency interference (by variations in the write-then-read delay) between the image written by software and the image displayed by hardware.

Second, the screen memory is probably dual-ported and double-buffered by storing updates, because they can be updated more efficiently as a block, and also so they can be delayed while the refresh cycle is reading memory to avoid bus access conflicts. So your updates will sometimes be delayed, or happen in bursts.

Third, you might be looking at persistence of vision in your eye, but your screen also has persistence of image. The technology (LCD or CRT) will take some time to reach full brightness at each pixel, and some (different) time to decay to black, and that will probably be different for each primary colour.

The problem, I think you will find, is a simple one.

Let us first look at what you would have to do if you were rotating a real disk in front of a camera. Most camcorders will give you a choice of shutter speeds. These speeds are the length of time that the shutter is open per video frame. If you use a very short shutter period, the chances are that each pixel will only see a single colour. If that is so you will see the individual colour sectors of your disk displayed on the screen. You may see some artifacts generated by the speed of the disk, the frame rate and the shutter period.

If you now use a long shutter period, more than one sector of your disk will pass a given pixel during the shutter open period. In this case the CCD detector will integrate the light falling on it during this period. The end result will not be a single colour but a mix of all the colours that have passed by, probably round about white.

Now, take a look at your software. Are you sampling the colour at each pixel over a very short period or are you integrating over a long period? I suspect that the answer is a short period. You cannot rely on the video card or the display to do this integration for you, this is not how they work. Basically you need to provide the integration, that would be provide by the camera in my example, in your software.

I did play with this with my camera that will give me shutter speeds from 1/60 to 1/500 seconds.

If you have further questions, please ask and I will get back to you.