Now that MIX11 is finished I took the time to watch most of the Windows Phone 7 related sessions looking for some interesting info that may have been missed earlier. The first thing to note is that Mango will be a big step forward in terms of developer tools and APIs (thanks to Silverlight 4) and third party applications performance thanks to the new and improved controls. Microsoft has apparently listened to the users and developer complaints and tried its best to fix all the major issue found in the OS’s current release (most of them listed in my Windows Phone 7 review here).
Let’s start with the performance improvements. I’ve recently seen people worried by the fact that the updated chassis now support the 800Mhz MSM7X30 SoC (dans from the 1ghz of the current QSD8250. Well, first off you must keep in mind that the MSM7X30′s 800Mhz Scorpion CPU has roughly the same real-world performance of the old QSD8205 clocked at 1Ghzso you should really worry about this. What’s also interesting is that the performance improvements brought by Mango will also help to offset the marginal 200Mhz clock-rate difference so the upcoming “cheaper” WP7 devices will perform just as well as the current handsets.
Here’s what Itsvan said in the Deep Dive session:
As we transition to Mango, there are some key changes we’ve made to improve even further over 7.
One of the key changes is that we handle touch input on the high-priority rendering thread. As a result, we’re able to get instant response to touch events even when you’re scrolling at high frame rates. To make room for touch processing, we’re bumping the rendering thread to 8ms.
Now that we don’t have touch on the UI thread, we can give it a lot more time at normal priority and our timeliness needs are less critical. This means the UI can run longer getting data ready for rendering, which means fewer missed frames due to late-coming data.
Finally, we can let the background threads run for longer since we’ve minimized the risk that they’ll interfere with high-priority touch events.
Taken together, these will allow us to scale our UI down from a 1GHz to an 800MHz processor as we broaden our device portfolio in Mango.
If you look closely, you can see that this budget leaves us with a little CPU left over that we can use to enable ‘other things’ if we’re smart about how we do that. We’re going to come back to that as we dig deeper into our multitasking design.
The other key changes which will improve third party applications performance are the new SIMD / NEON-ARM support for XNA appls (has to be coded) and Generational GC (Garbage Collector) which I already talked about here. Additionally Microsoft is providing new Sliverlight controls to replace the most crappy ones currently used: the ListBox control and WebBrowser control.
The Sliverlight 4 clipboard API will enabled copy and paste scenarios in third-party application similar to what’s possible in the OS native apps (like long press on an link or item to copy etc..)
Besides the improved Listbox control which will essentially make the vast majority of the current application a lot more enjoyable, Microsoft has also integrated a new off-thread Background image decoding capability allowing the device to retain a smooth UX while loading up images in the backgroud. Appliation like the Flickr, Kayak, Netflix etc will greatly benefit from this.
Last but not least: 32Bit color support in Silverlight application. As I’ve said a while ago; third-party application (and most of the native OS apps too) are rendered in 16bit right now. Unfortunately devices like Samsung’s Omnia 7 and Focus (and some of the HTC devices with the newest firmware) lack proper color dithering. The result is really bad color banding and forcing 32bit or 24bit across the OS via registry hacks like I’ve seen done lately isn’t a solution given the huge performance impact. with Mango (and SL4), developer will have the ability to run their application in 32bit (unfortunately this setting will affect the whole app, the dev can’t specify if he wants only a certain part of the app to be in 32bit). The only downside is that it will slightly degrade the perfs of the app. Now what would be great is if Samsung (and lately HTC) fixes the stupid dithering issue themselves…(btw the Super AMOLED display are 32bit panel not 16bit like somebody in the audience said during one of the Q&A sessions).
The Silverlight 4 Webcam API will allow developers to access the camera’s raw feed and to tons of really cool things with it (mainly augmented reality things in association with the new Motion Sensor API). Video show with this way will be encoded in .mp4 (no resolution was mentioned though) but can only be saved in the application’s isolated storage (not the device’s zune storage like vids and pics shot with the native camera app). the new MediaElement control will also now use the device’s hardware scaler when rendering videos (which are not in 800×480) to improve battery life (up to 1h30 according to ealry benchmarks).
You should also check out the Motion Sensors API session to see how cool it is and remember that most of the AR stuff can be done without the Gyro, it will just lag more than if there was one (btw the HTC 7 Trophy dev phone used apparently has a Gyro according to Mark Paley). The XNA session has some pretty cool demos showing the integration of the silverlight with XNA and video playback integration into 3D elements.