Here’s a small tip for those of you who want to debug performance in a Windows Phone Silverlight app with the frame rate counters, but have the System Tray visible – hide it.

The counters currently show up behind the system tray (since technically the tray is a system overlay which is drawing over the surface available to your Silverlight app), so hiding the tray will show the counters.

Don’t forget: to re-enable the system tray when you’re done!

Here’s an awesome gotcha when moving from a desktop Silverlight application to a Windows Phone 7 application – make sure that your media (wmv) files are set to “Build Action” = “Content” and not “Resource”.

You’ll notice that if you do something like:

<MediaElement Source="somevideo.wmv"/>

Where “somevideo.wmv” is set to “Content”, then the Windows Phone Developer Tools (ie. Visual Studio) will underline the "Source" attribute and recommend that you set it to “Resource”. This is a hangover from the desktop and is something that I hope will go away – you can safely ignore this warning (it won’t appear in your build windows).

What’s Wrong With “Resource”?

For those that want more, here are the potential problems you can run into when setting your media to “Resource”:

1. When a video file is compiled as a Resource it incurs an extra space and performance hit every time you play it, since Silverlight does extra processing to extract the video from your assembly (DLL). In the case of “Content” the file can be read directly from disk (or memory) and you’ll get instant start playback.
2. Anything that makes your DLL larger is evil (from my point of view) – you want your assemblies to be small (think “quick and nimble”). Although the size doesn’t always directly affect load and memory time (there are a couple of other factors at play here) this helps eliminate one more possible bottleneck.