It seems every couple of months we get barrage of mixed messages about livelihood of platform we all make living from and its that time of year again. This time what set off the wrath of community was unveiling of Windows 8 Metro UI touch centric interface and statement that it was built using HTML5 and JavaScript. There was no mention of WPF or Silverlight or .NET… Understandably lot of people are up in the arms.
I have no first hand knowledge of what the plans are for Windows 8, but here are my thoughts based on what we know today. Windows 8 will as every single version of Windows still run GDI based apps. They call it Classic mode, but there will be no dropping of that mode any time soon. That means that all apps that are running today will run tomorrow on Windows 8. Best bet for those apps in my opinion is still WinForms and not WPF or Silverlight. Why? GDI is closest to the Windows platform since it works directly with Windows messages and drawing canvas and those are not going away due to must have “feature” to continue to support millions of apps already developed for Windows. And I bet we will find the way to integrated those with the metro tiles…
Why new User Interface technology is needed?
We know that there will be no investment to further speed optimize WPF (I can’t find link with that statement right now, but when I do I will add it). And since Windows 8 will run on ARM processors so you can have those long run-time tablets, that rules out the WPF. And it rules out Silverlight to some extent unless serious performance optimizations are done. Why? Silverlight is for example slow running on say MacBook Air, in fact so slow that it cannot be used for anything serious. It is not snappy enough when running on netbooks as well. I bring those up since that is about performance of ARM processors running tablets today.
So for Windows 8 to run well on low powered tablets new UI technology is needed. We know that Internet Explorer 9 and 10 uses hardware accelerated rendering that is snappy and fast enough so it is no surprise that first demos of Windows 8 touch based input shell are written using this combination. However, I do believe that HTML/JavaScript are simply not as productive as .NET stack which is evident to anyone who tried both. Additionally, you can’t really write apps like Visual Studio in HTML/JavaScript. It would be madness. This HTML/JavaScript combo for UI shell is nothing new, Palm WebOS did this already, its not bad but nothing spectacular…
What is new UI tech?
I don’t know, but it has to be hardware accelerated so it uses the graphics chip to render all of the UI. It is possible that they resurrect Visual C++ to target platform natively and it is possible that they start compiling .NET CLR directly to native instruction set, but I think this is unlikely since there is ARM and Intel processor architecture and you’d need two compiled versions of native code to target both.
My bet is on the .NET based stack possibly compiled directly to native code with new UI layer that is heavily hardware accelerated. We will know in couple of months whether these predictions hold true.
What do you think?
I think you’re saying some weird stuff here, Denis.
WPF uses hardware rendering, much more extensively than SL, using D3D9. In my experience writing a real non-trivial app with it, it runs fine on an Atom-based netbook with Intel graphics. (I have two of them as test machines.) I’m dissatisfied only with cold startup time, which is painful on slow CPU/disk machines.
Of course, to get a smooth running WPF app, you need to understand performance, how WPF works, pick a target hardware spec, and know the limits. But the same is true for anything including HTML/JS. Hardware acceleration doesn’t magically make everything fast and free.
Also, the .NET Framework (CLR, BCL) is already compiled to the native instruction set. Parts of the .NET Framework that are managed code get NGEN’d to native code at install time, or queued for immediate NGEN’ing in the background depending on which OS you’re running. And of course, .NET application and library code is also compiled to the native instruction set, always, whether you use NGEN or you let it happen at runtime via JIT.
Finally, remember that SL apps on WP7 are already running on ARM. All WP7 phones use ARM CPUs. From what I hear about SL WP7 app dev (I don’t own a WP7 phone), perf is a challenge but it’s doable and getting better in updates to the OS. If apps can be made to run smoothly on a phone with an ARM CPU, why not on a tablet with an ARM CPU?
Thanks for comments Tom. Its little strange if you don’t have all the info, but I do know that there will be no performance improvements on WPF, even though it is known that this is needed. MS team said that it is not worth the time. I ran lot of WPF apps on Atoms and they are not what we would call snappy, i.e. not like native iOS apps on iPad and that is the benchmark today. I see some big companies that were using Windows TabletPC’s now switch massively to iPads. Questions they are asking is: Why the iPad that is underpowered compared to most PC’s is outperforming them on UI and general usage front. WPF apps on low-power hardware feel for the lack of better word heavy. WPF does use hardware acceleration, but implementation of that is not as good as it should be. This gives great info on this: http://jeremiahmorrill.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/
I know that .NET instruction sets gets compiled into the native instruction set but by default it happens at run-time with just-in-time compilation. On slow processors and large apps this is noticeable hit, couple of seconds. However, this is easier to solve so that is why I targeted my thoughts on UI side of the things.
SL apps do run on WP7 and ARM, I have WP7 phone. It is not bad at all. But, what they did for WP7 does not “scale” up to tablets because WP7 OS does not run “legacy” Windows apps, it is not backwards compatible… My first reaction on Windows tablets is that WP7 should be simply ported to larger screens, but alas that’s not what is being done exactly because WP7 OS is not Windows OS and there is perception that if you force people to rewrite the apps they might simply switch to different platform, iOS or Android…
I’m familiar with Jeremiah Morrill’s post about the performance problems of drawing ellipses in WPF using the GPU. I remain suspicious of his message, the way he went about delivering it, and his motives. Unfortunately the true picture here is so complicated that it’s difficult to refute in a blog comment (for me at least), but suffice it to say I think it’s a huge and unreasonable leap to go from the very specific scenarios he examined and say those problems are what cause the overall heavy feeling that can be observed in real WPF apps. Also consider that 2 weeks prior to that post, he blogged about an introduction to “DirectCanvas”, his own competitor to [a tiny subset of] WPF.
Anyway, I’m curious about how the need for backward compatibility in W8 is able prevent the scaling from phone to tablet that you mentioned. Is there some specific resource or design constraint you have in mind?
Its not only his message which is valid and has merit, but comments from WPF team that I can’t find link to yet… However, don’t you think it is interesting that Windows 8 UI is being shown off as HTML/JS combo instead of either WPF or Silverlight when they are clearly superior as technology? The only conclusion one can draw from that is that they are not fast enough.
Regarding WP7 scaling to W8, there is heavy optimization they did for WP7 and Silverlight that for some reason has not trickled to Windows yet. I have no doubt that WP7 could run on iPad style device, but strategically that leaves all “legacy” Windows app in need of rewrite and they see it as killing the goose that gave the golden egg so that is why WP7 will not go on tablets…
Personally I’m inclined to believe that the choice of HTML/JS in this case is not related to application performance. It seems more likely to be a political and/or long-term strategic decision. It is interesting to view it in the light of MS’ past failures to promote HTML/JS on the desktop, as well as the failures of its competitors to use it for native apps.
Unfortunately all we can do right now is speculate, since the order from MS high command is to not disclose anything to developers for several months. It’s hard to predict the future but I think it’s safe to say that we have interesting times ahead of us.
Tom, I like how you put that in words, thank you, very measured. Indeed, interesting times ahead, but important to keep in mind that everything will keep on working for some time in future. Lot of people get into the panic mode with these announcements, but truth is things change, we just don’t use Clipper to write DB apps anymore, but they continue on running, which is what matters.