There are problems in a couple of different places where we do image
caching and use heuristics to determine when to use which version of
an image (based on the types of operations that are faster in either vram
or system memory). In some places, the heuristics are not smart enough
to catch important cases. In other places, there are simply bugs.

Bug:
In our hidden-acceleration mechanism for toolkit images (including images
created by createImage(w,h), whenever our image has been modified and therefore
needs to be backed up to the cached version, we don't record that a dirtying
operation has taken place. So we automatically copy down the bits to the
cached version every time. What we should do is record that the operation
has dirtied the image and therefore we may not want to use the cached version
(our usage is based on the number of times we copy from that image; as the
number of copies increases, the advantage to the cached version increases.
But we obviously don't want to copy down changes and then use the cached version
every frame; we're just duplicating work and losing the advantage of caching).

Heuristics problem:
Currently, we base a different image punting mechanism (where an image may live
in vram or system memory) on the number of times we do unaccelerated reads
from the image versus the number of times we try to do accelerated copies
from/to the image. These comparisons are calculated sequentially; we track the
number of reads between Blt's and vice versa. But this is not good enough to
track an important case of doing one huge read per frame (and a lot of other
similar cases). If an application is doing one large translucent operation
to the image very frame, then that image should live in system memory.

I have attached an example app that shows the problem for the heuristics
problem above (the other bug is not as noticeable to the end-user, so
developing a test-case is not easy; it is best seen through code tracing
as we watch images being copied around too often).