I'm not an expert at graphics per se, but I understand a bit. I believe that drawing an actual in-memory image via drawImage() is more efficient (i.e. faster) than drawing shapes yourself (e.g. fillRect(), drawLine(), etc). In either case, your app will need to draw in image to the screen, but when you use fillRect(), etc, it also needs to perform the calculations and actually create the image.
In the example you give, the difference would probably be unnoticeable, but I suspect you were just providing a simplistic example.
If you're talking about persisting the images, though, then storing the image itself would generally (but not always) be more expensive than storing the instructions to render the image. Take your example. To store that particular image, depending on your file format, you'd have to save out every byte that makes up the 200x200 yellow square (although of course, formats like GIF and PNG dramatically help out). To save out the instructions, you'd simply need to save something that says to draw a 200x200 yellow rectangle. That's why "vector" graphics (e.g. that describe the geometric shapes to be drawn) often result in much more compact file sizes than "raster" graphics (e.g. that describe how each pixel in the image must be drawn).
But back to your question... at the point of doing your animation, you'll already have everything in memory that you need to draw the image. So doing the calculations over and over again is just a waste of cycles. The one caveat, of course, is that I am assuming that the frames of your animation are not going to change.
Dave Taubler<br />Specializing in <a href="http://taubler.com/articles/" target="_blank" rel="nofollow">Java and Web Development</a>