Digital Transfusion

Putting the internet in your veins!

The way I see CacheMode in Silverlight

2 comments

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.

Tags: ,

2 Responses to “The way I see CacheMode in Silverlight”

  1. Martin says:

    You can’t just cache everything. That will destroy performance even more.
    Every once in a while even a developer has to think. And I don’t think this will change anytime soon…

    • Ryan Plemons says:

      I agree that you can’t just cache everything, but the point I was trying to make is that the developer shouldn’t be the one to make that determination by default. I can figure out the right way to do it, but it will take me a lot longer than an algorithm or a few set rules in the framework that would help speed that up. As long as the ability to override is there anyway.

      Like it or not you HAVE to use BitmapCache or your application will be slow in many situations…the problem is that a lot of developers out there don’t know where to draw the line. Like you said, they can over-cache their application and degrade perofrmance everywhere. Right now there is the potential to do a lot more harm than good.

Leave a Reply