To view parent comment, click here.
To read all comments associated with this story, please click here.
I don't entirely agree. I think that managed code can still be an answer, but the design of the frameworks has to be something carefully done.
It is actually quite astounding how the WinDiv inside Microsoft did in a few years what DevDiv couldn't, which is make a XAML stack blindingly fast and fluid.
Silverlight is just a bunch of compromises for cross platform (Remember, the thing started as a cross platform BROWSER PLUGIN).
- XAML is parsed, not compiled (Honestly, not sure if this is still the case in WinRT, but I know WPF uses compiled XAML)
- Software rasterization, even for pixel effects. The only HW acceleration are GPU cache'd surfaces with BitmapCaching and (WP7 and SL5 only) composite thread animations like Opacity and RenderTransforms.
- On WP7 it uses the .NETCF which I would bet has code gen which isn't up to par for ARM. I remember reading somewhere that the Windows team made their ARM JITTer very efficient for the Metro Profile on Windows 8.
All in all, I wouldn't let a so-so (Because let me make this clear, it has rough edges but it's far from TERRIBLE.) experience on WP7 with managed code make you sour on the idea.
I believe the idea can work.
Well, consider that WinDiv is many times the size of DevDiv. And that they used Silverlight as a guide for designing the WinRT API -- but removed half of the functions.
True, they had to write the runtime from scratch in C++. But remember that they had C# source code to look at as they were doing this rewrite. It's a lot easier to rewrite C# code in C++ than to write it from scratch the first time around.
In other words, they had a very constrained problem space. That left plenty of time for performance tuning, refactoring, etc.




Member since:
2006-08-26
I agree with your take on managed code. On something like a lower power, memory constrained device - go native.