When a 'z' just doesn't cut it... (Oren Nachman's random notes from Microsoft)

August, 2010

  • Randomisation

    BUG: Silverlight Crashes (Along With the Browser) When Profiled


    It's one of those bugs... If you've tried profiling Silverlight lately and you've run into a consistent crash in Silverlight which brings down the browser, but only on specific projects then this bug is for you.

    Basically, profiling any Silverlight app (plugin or OOB) that takes advantage of Shaders will cause Silverlight (and its container) to crash. The only current workaround is to remove the shaders before profiling (possibly with an #ifdef if you are so inclined). This is slated to be fixed in an upcoming version of SL 4 (though no release dates yet).

    Note: people often get scared of crashes since they can indicate a security bug - but this is not a security issue (the profiler puts us into a bad state, causing the crash). 

  • Randomisation

    WP7 Silverlight TextBoxes No Longer Scroll


    There's a change in the pipeline that will be hitting the public Windows Phone 7 images at some point soon (post the current Beta), which removes the ScrollViewer from a TextBox's template.

    What does this mean?
    Basically, long TextBoxes will no longer scroll when you gesture over them - the gesture is ignored and there is no visual reaction. Tapping remains the same (the keyboard pops up) as does tapping and holding (the enlarged caret is shown, and you can use this to, sort of, scroll).
    How do I work around this?
    Most scenarios do not require scrollable TextBoxes, but if your's does you can either place the TextBox inside a ScrollViewer (though this can cause some texture issues), or preferably re-add the ScrollViewer into your TextBoxes template, so that it still scrolls as usual.


  • Randomisation

    WP7 Perf Tip #1: Test on Device


    I'm kicking off a series of posts about Silverlight perfofmance under Windows Phone 7 with a a kind of obvious one, but one that is important to keep in mind from the get go.


    • Test your code on device as much as possible 

    But the Emulator is awesome?!?

    True, the emulator, otherwise known as the x86 Device Emulator, or simply XDE, is awesome, but it is still not an accurate representation of a device. In fact since the XDE is usually so smooth, it's extremely easy to fall into the trap of adding more features "because it works on the emulator".

    The Hardware

    The emulator restricts itself to one core, adds artificial Sleep()'s and limits the amount of memory it is happy to eat up (so it won't just chew through whatever is available), but that still isn't enough.Chances are that even running at one core the emulator is still running faster than the device (most cores today are going to be running faster than 1GHz and chances are you are going to have less things running on that core than the device does). Throw in a desktop GPU which beat a mobile GPU handsdown and you've got a winning combination. If you happen to have an older machine, then the XDE will simply run like a dog - and you won't be able to tell if your app crawls because of your code or because of your machine.

    But I don't have a device!

    Common problem, especially in these trying, pre-release, times. Fear not though! Your local Microsoft office most likely has some devices and can help hook you up. Shoot them an email and let them know that you are working on an app, include a description and some screenshots from the XDE (to sweeten the deal) and they should be able to help.

  • Randomisation

    WP7 Perf Tip #2: Know your ProgressBar


    Take Away's:

    1. Do not use the built in ProgressBar straight up, use Jeff's template 
    2. When you're done with an indeterminate ProgressBar, make sure to toggle IsIndeterminate to False and Collapse the bar
    3. General: Always make sure to stop animations / remove animating controls when they're no longer needed 

    Some Background:

    Due to a bunch of different reasons the shipping ProgressBar control is suboptimal and will actually be UI thread bound - meaning that if your UI thread is stuck working, your ProgressBar will be stuck as well. Not a great situation for a ProgressBar, huh?

    That said, we're not leaving you high and dry. Jeff Wilcox has a great solution which changes the template for the ProgressBar to only run on the Render thread - meaning that it will continue ticking, even when you're doing your heavy loading work on the UI thread. That said, it still comes with a gotcha - don't forget to set IsIndeterminate to False and to Collapse the bar once your done (instead of just setting Visibility to Hidden) so that the ProgressBar doesn't continue to tick in the background, eating up Render thread cycles.

    As a general rule, highlighted especially by the ProgressBar, you should always make sure to stop animations (not pause) and remove / collapse animating controls when they're no longer needed.

    Remember: just because you can't see a animation / control doesn't mean that it isn't there doing work.

Page 1 of 1 (4 items)