Why Silverlight 5’s 3D is (almost) useless

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?

Comments (17) -

  • Yeah, it's tedious just to explain how to set 'allow' 3D graphics on SL permissions Tab. The user has to go through a 6 click process plus a browser refresh on any new 3D url he visits!
    Oh well, the XNA api is very nice for those persistent enough to see it.
  • well, it make sence, as this is potentialy SECURITY RISK! God knows what you will execute on GPU. Mb you will find an exploit and gain access to shell, or you could crash client computer.
  • yes, i aslo surprised why not to make a dialog request like they did with webcam...
    I didn't know anything about this restriction and was confused why my 3d project doesn't work in rtm.
  • This is terrible news.  I am building a great game with 3d assets already lined up.  I hope that they add a dialog in a suceeding release to make this as easy as the webcam control.
  • "more so than WebGL at this point"

    Why do you think so?
    Do not forget that MS excluded XP users. Without them SL XNA can't have bigger market share than WebGL!
    Also no luck with Mac users! Nor with mobile users!

    Firefox (everywhere), Chrome (everywhere), Safari (on Mac os, but disabled by default), Opera12+, Firefox for mobile, N900, BB Playbook, Sony Ericson Xperia, they all have WebGL!
    There is ChromeFrame, and IEWebGL plugin for IE too!!

    This works on MacOSX, Linux, WindowsXP+, Android, QNX...
  • Przemo_li:  this works exactly the same way in xp too, so no its not excluded. The IE market share is huge, so yes more people would have been able to use this than any other webgl browser combined. And you wouldn't have to rely on an unfinished standard with different levels of browser implementations. I'm not saying WebGL isn't interesting, but for deployment today I just don't see it.
  • 1) WebGL is finised! For a long time now.
    2) XNA in SL is disabled by default on old gpu drivers architecture. So for XP users there it is turned off by default! (so 40% is left in the cold by default).
    3) Turning on disabled gpu driver is somehow complex (there is no pop up, you need to give user hints how to change it in SL settings).
    4) Again. Asking users to install ChromeFrame, or IEWebGL is easier than changing SL behaviour.

    When users use WDDM drivers, then SL is better option (when comes to level of support), but its not majority of market.
    And MS may limit number of whitelisted WDDM drivers even more based on some driver specific bugs.

    (BTW did you know that some of WebGL unreadines comes from lack of MS support, plenty of gpu drivers bugs could be ironed out much quicker)
  • Przemo_Li : you obviously didn't read my article. You are talking about the behavior in RC. This changed in RTM and is now disabled on all GPUs by default. That's what this whole article is about.
    You can tout WebGL and workarounds all you want. But this is a Silverlight blog for people who likes to code in .net and don't like to spend their day in JavaScript. We like compile time errors and type safety and the benefits that the the Visual Studio tooling gives us. Our customers love it because they can get a cheaper solution in less time and don't care if it works on all platforms and the cost associated with ensuring it does.
    JavaScript is great for some things too (like cross platform if that's the project requirement) but this is not the blog for you. Sorry.
  • I've reread whole article, and now its a different story.

    However I still insist that MS shipped (they even advertise this feature in their announcements) insecure solution.  While they have refused to do so in case of WebGL. If its case of changing mind, than MS should ship turned-off-by-default WebGL in next (or next after next if IE10 will be released too soon) IE. As it is now its plain example of double standards.

    I know that SL have its use-cases! I know its good! I'm not disputing it. However MS did in the past used unfair tricks to promote its own "standards" for the web. No one won in those situations.

    And I'm here because you know what's going on in SL, and I want to learn something (even if I sometimes misunderstand text I read).
  • raphael: I'm not sure what your point is. Silverlight works in more than just IE.
    Also public facing consumer sites is a different story than B2B or internal sites. There I usually see uniform platforms and browsers deployed, and the issue with crossbrowser and crossplatform is very small - especially when they need to look at the bottom line and want a cheap solution. The issue with a certified officially supported plugin like Silverlight isn't a big deal to deploy either. The IT department can push that out to everyone in just a few clicks.

    But of course if a certain project requires it to work on iPad then yes Silverlight is not for you. But there are LOTS and LOTS of projects where that's not a requirement. Or where they choose to build a native app for the iPad and a Silverlight based app for the browser, because they often get a better experience that way. Or other times downgrade to JS and a limited experience when on a phone of iPad.
  • For the love of all things great and small, please keep your comments on topic.  Don't turn this into another browser preference circle jerk.
  • Ouch, I can't believe they haven't made it easier. I noticed such behavior when I installed SL5 Beta, it was so ridiculous that I was sure that was just a placeholder... oh well this is frustrating, this means no public-facing 3d in SL5.
  • Andrew: what do you mean in beta? This wasn't an issue in beta nor in RC. That's partly why I'm disappointed since this changed between RC and RTM.
  • This whole thing just makes me sick. Why... WHY... did they not implement a simple permissions pop up? "Grant 3D access? Yes. No."

    I've been working on an Silverlight 3D/XNA app for months, and this simple little thing just completely killed my project. Massive waste of time and resources. There's no way I can ask my users to go through those complicated steps.

    What a gigantic bummer. Silverlight is dead.
  • ddf
    after months of  development my own project seams to heading  for disaster just because i thought i could rely on sl for 3d . thank you ms
  • ddf
    i think i will use my initial balder controllers and views to lure in users and then after they are commited enought go to the valay of death with the impossible permission adjustment. there is any good thought to bypass the issue from marketing point of view and not technical until ms understand what the have done .
  • Any update on whether this was fixed in 5.1?  

Add comment