So Silverlight 5 finally hit the web this week, and there’s a lot of cool new features – some of which I’m very excited about, but probably the biggest feature ever added - the 3D XNA API that allows you to render directly to the graphics card using the new DrawingSurface API - I’m not so excited about any more. Why? Because between the RC and RTM release this feature has been heavily crippled. Here’s an excerpt from the recent blogpost describing the change:
[…] you may experience security errors with Silverlight 5 RTM when you want to use the wonderful new 3D feature. In fact, some graphics drivers may allow malicious code to execute. That may lead to an unwanted hard reset or a blue screen.
Starting with the beta version, to protect users for this kind of trouble, we initiate a first scenario where all Windows XP Display Driver Model (XPDM) drivers on Windows XP, Windows Vista, and Windows 7 will be blocked by default. Permission will be granted automatically in elevated trust scenarios and Windows Display Driver Model (WDDM) drivers will not require user consent at run-time.
But as always, features, including security features, continue to be refined and added during post-beta development.
And for the RTM version, there were a number of approaches considered to further improve security and stability, but the solution to block 3D in partial trust by default was the best option for this release. Permission is still granted automatically in elevated trust scenarios.
So already during beta and RC, we had a security limitation that certain old type of display drivers would disable this mode, unless you ran in full trust. Considering the uptake on WDDM, I didn’t consider this limitation a big problem. After all technology moves forward, and old tech sometimes needs to be left behind. After all one of the reasons for moving to the WDDM model was to stabilize the system.
Post RC this limitation was increased to be across all systems and display drivers. I was lucky enough to get a heads up about this a little over two months ago, but I feel truly sorry for the people who had been betting on this feature and are ready to release their 3D apps now that RTM has hit. The communication of this limitation shouldn’t have stayed within a small group of people under NDA, but should have been communicated out to the community. It probably didn’t happen because it could probably have fueled the “Silverlight is dead” fire (and rightfully so). I would have like to have seen a more open discussion of this, similar to what the Windows 8 team has on their “Building Windows 8” blog. In June the Silverlight Team had promised that the DoS issue that beta and RC had, would be mitigated and developers were counting on this feature.
So I’m not saying that security shouldn’t take precedence, but I would have like to see a more focused effort to either improve the experience – either by dedicating a lot of resources to weed out the security issues, delay the release, or at the very least make it easier for users to opt in. – perhaps communicating that this is a temporary limitation and will be resolved in a GDR update. Considering the late change, I get that the Silverlight team didn’t have much time to turn around and improve this experience. However, there’s already a feature like this for when you want to use the webcam that works much better. When I in Silverlight want to use the webcam, I ask the user for permission, and I’m met with the following dialog:
It’s pretty easy and it’s clear to the user what he/she needs to do. I wish we had gotten a similar dialog for enabling 3D. Instead, now in Silverlight, all you can do is detect that the 3D capability is blocked and try and describe to the user what to do. These are the steps you would have to guide them through:
- Right click on your Silverlight plugin.
- Click the “Silverlight” option.
- Go to the permissions tab.
- Find the domain that hosts the .xap file (which might not be obvious since it could be different than where the website is located).
- When you find the entry (and this list could be quite long), you have to click “Allow” – no indication here what that really means for the casual PC user (how do you use a blocked display driver?!??).
Was this really the best experience we could have gotten? It’s actually easier to ask the user to install the app in full trust (which is an even unsafer mode), than the above experience. I’m sure Average Joe would not like this experience, have trouble finding this out, and probably even be scared to death to do anything he’s not used to doing (I know my parents wouldn’t ever get through this). So all you are going to see on your website is a plugin container that just sits there unused, and not getting to show how awesome this thing could really have been.
It’s such a shame, because this API can vastly improve rendering performance in many scenarios, and opens up an entirely new group of 3D based web based apps. And it would have worked across a wide range of browsers (more so than WebGL at this point).
The 3D capabilities are still great for out-of-browser apps and internal line-of-business apps where it’s a lot easier to deploy an app in full trust (especially with SL5’s new in-browser full trust feature). But are that really the type of apps where you expect to be using the 3D feature a lot?
Subscribe