views:

56

answers:

1

i was told to design a paintbrush program in 2 variation , one that uses lots of space and little cpu and the other vice versa.

the idea (as i was told- so not sure) is somehow to save the screen snapshots versus saving XOR maps (which i have no idea what it means) who represent the delta between the painting.

can someone suggest a way or add links to related material ?

+4  A: 

The obvious place to put the screen shots to use would be to implement an "undo" command. The simple, memory-hog method is to take a snapshot of the screen before each action. If the user hits "undo", you can restore the old screen.

To save on memory space, you save only the difference between the two screens, by XORing them together. By itself, this doesn't actually save any space, but it sets all the unchanged pixels to 0. To save space, you'll then need to apply some sort of compression. Given that you can typically expect fairly large areas that are all zero, a run-length encoding will probably be quick and effective. For a run-length encoding, you'll typically turn a string of identical bytes into two bytes, the first holding the length of the run, and the second holding the value. For example, 75 zeros in a row would be encoded as 75 0.

If you wanted to go a step further, instead of saving XORed bitmaps, you could look into using a metafile. A metafile records the actions taken at the level of Windows GDI calls, so (for example) if you drew a red 100x200 rectangle at 10, 100, it would record essentially that -- i.e. instead of the twenty thousand pixels, it would save an identifier saying what GDI function to execute, and the parameters to supply to that function. In a typical case, this might average around 15-20 bytes per "command" executed. At the same time, it does (often) involve more computation -- for example, if you draw a circle, re-running a metafile requires re-rastering the circle instead of just storing the bits it produced.

Jerry Coffin