@Bass: I'm guessing that WinRT/XAML/WinJS is as much about consolidating many internal frameworks as it is to give external developers THE WINDOWS framework for apps..
Dec 15, 2013 at 1:42 PM
seeing as corefx.dll vs mscorlib.dll was brought up here .. this is a link from a while back discussing the reasoning & hints at evolution of mscorlib/system dll's
Xbox One update fixes a "dashboard sluggish" issue...
I really hope that the new "Start menu", if it really does come back, isn't just a snapped start screen...
I want it windowed, in a popup or flyout. Just give me something like windows 7 start menu BUT totally rebuilt with tiles and windows 8.1 bing search ..
That whole snapping really annoys the hell out of me on desktop, its cool for touch devices BUT for keyboard/Mouse world I don't want that!
This dock with the VenuPro is a great combination
as for resolution... its 8" ... 1280 x 800 is definitely good enough for that size .. and if you want to dock it to 4 monitors (attached clip above) then that's when you'd want high res..
Anyway im loving mine, and I got it for $199 ... AND ITS A PRO, not that crappy RT version!
lets not forget that Silverlight became the foundation of
1. XAML on Windows Phone (7.1/8.0) ...
2. Windows XAML (WinRT-XAML) , Jupiter. Thou one can argue it has been greatly refactored!
One question im dying to find out is what is the Windows Phone XAML story going forward. Currently its Silverlight-XAML (Windows Phone version). BUT it could possibly be changed to WinRT-XAML (Jupiter)??
Another big question is , will MS push a unified XAML story on desktop. At the moment the desktop xaml story could be
d) Windows Phone - XAML (Silverlight)
Nov 17, 2013 at 6:38 PM
@felix9:Chrome recently released pNaCl is it possible that your above mentioned ilc behaves similar to pNaCl's intermediate format ?!
NaCl (tech for which pNaCl is based on) generates compiled binary modules which can then be downloaded by a user's web browser and executed on the local CPU.
portable (p)NaCl - changes this by generating an intermediary format which the browser then takes and completes the final compilation step for the relevant architecture ARM/x86 etc
@FuncOfT: totally agree. in our case JIT startup time coupled with iis process recycles are definitely expensive for us..
Also nice to point out a particular comment on the anandtech article ...
DX and OpenGL are too high level to expose some of the features that are likely exposed by Mantle, but that doesn't mean thy cannot benefit from some of the features. Someone below mentioned how Mantle is probably just a "scene graph". Very unlikely. More likely is the enhanced draw calls they are referring to is the same thing Nvidia presented a few years ago via OpenGL extensions - bindless graphics. With enough work, the API can also then start harnessing GPU memory as pointers instead of data bound by a set of registers, which is where OpenGL and DX mostly start breaking down, and cannot do this today. Direct memory access can have huge benefits.
Wait. I think the question is could DX and OpenGL drivers be written to use Mantle rather than direct hardware access. The answer is yes. Mantle is providing a virtual GPU that is a direct 1:1 mapping to hardware functions. It might not be quite as fast, but it should be pretty close because it wouldn't need make any more mode switches than it would for direct hardware access. The benefit would be in driver development. Once a particular OpenGL or D3D version was implemented using Mantle, it would work for any AMD GCN hardware well into the future. It would give AMD a set of stable, optimized D3D and OpenGL drivers that would work with any future GCN devices for quite some time and require far less code maintenance.
even the official AMDRadeon twitter account recommends reading the AnandTech article on Mantle
"Understanding AMD's Mantle: A Low-Level Graphics API For GCN" - http://www.anandtech.com/show/7371/understanding-amds-mantle-a-lowlevel-graphics-api-for-gcn