If you have been doing any kind of Silverlight or WP7 work then you are probably already aware of a property called CacheMode on all of your controls. This magical little property can improve the speed of your applications by caching the visuals instead of redrawing them every time.
This was EXTREMELY noticeable when I converted Zero Gravity to WP7. My jaw literally dropped to the floor the first time I ran the game. The speed was far from adequate… In fact the game was barely able to run. Here I saw demos at Mix with a device that were able to run full 3D without so much as a flicker; and here this very, very simplistic game was being brought to its knees. There is hardly any animation the screen is full of mostly static content. So how could this be performing so very poorly?
Of course with a liberal dose of the CacheMode=”BitmapCache” the application soon started to perform pretty well. But, did I use CacheMode correctly? Should I have included it on more elements? None of them? All of them? I am left with a problem of knowing “when is the application optimized to its peak efficiency?” This begs the question…
Why do we need CacheMode=”BitmapCache?”
Asking a developer to handle caching like this is like asking a 2nd grader to do their homework and then leaving them alone and unsupervised. Sure, some kids will buckle down and get their homework done, but more often then naught the 2nd grader is going to get distracted. This could make them take longer to do their homework or worse yet they won’t do it at all. (I know playing a game on Xbox would seem pretty awesome compared to doing homework!)
Caching is something that should absolutely be taken care of by the framework. Nobody is going to know performance enhancements better than the developers that create the API’s we all know and love. Go watch Seema’s performance presentation at Mix10 for an example of how complicated performance can be. Sure, there may be edge case scenarios that require developers to reach in and take the reigns, but by taking the initial performance enhancements out of the hands of the developers you ensure that EVERYONE will participate “out of the box.” Seema’s presentation illustrates how very fragile the current Silverlight rendering pipeline is. Anything we can do to remove “problem points” can only help the framework in the long run.
There are many Silverlight (desktop) applications in circulation today do not implement CacheMode at all. They didn’t need to because the applications ran fast enough on today’s beefy computers. But imagine if all of these applications were optimized from the start! The UI could be more responsive and CPU usage could be reduced without the end developers writing a single line of code, and THAT is what we should be striving for.
Lets hope that future versions of Silverlight take control so everyone participates. Opt-out, not Opt-In.