Archive for the ‘.NETv3’ Category
This article could have also been called :
- "I accidentally wrote something for the Mac"
- "Goodbye WPF… Hello Silverlight"
- "Is Silverlight the next (and first) big thing for cross platform 10 foot?"
So before I explain all that – I’m proud to report that the AllBlacks "Silverlight 1.0" Sidebar + Desktop Gadget – has just been launched and is now available from the AllBlacks website at :
As it’s made with Silverlight 1.0 – so that means it not just for Vista users – it will actually work on WinXP, Win2003, Mac’s and soon Linux and 2000…
Otherwise here’s a couple of pics – pictured below is the Vista32 sidebar Gadget (in it’s undocked state) :
And tada – below is it running on the Mac - playing back WMV video… (gotta admit the popup window border/title looks way sexier on Mac+Safari then what you get with browsers on Vista, XP – which show really ugly borders).
And now for the Technical Stuff…
So anyhow as per those pictures above – I’ve been fully immersed in Silverlight 1.0 for the second half of last week (inc a chunk of the weekend) – and this came about last Wednesday when I spotted the ‘Silverlight 1.0 SDK’ on MSDN Downloads at around 10am. (and gave a very clear indication that Silverlight 1.0 was about to be released within a few minutes/hours/days). Sure enough the announcements appeared a few hours later and the final release was launched.
Right at that very moment – I was battling with trying to optimize a WPF .exe/windows project (The AllBlacks desktop + sidebar gadget) that was due to be released this week. I was running out of ideas (had optimized everything as much as possible) – and two major showstoppers were looking to be unwinnable – Excessive Memory/CPU consumption (WPF takes 60mb just to show a blank form with no code – and most transitions like fades use up lots of CPU) – and Video Playback/Graphics corruption on NVidia Cards (after waiting nearly 12 months – NVidia has still not fixed their drivers).
After looking a number of sample Silverlight apps that were around – it became very apparent that although Silverlight was essentially a subset (or cutdown version) of WPF – the core engine running it was an altogether different beast. The Silverlight implementation was lean, mean, and was able to do all the fancy shmancy animations without making much of a dent on the CPU at all (I don’t think I managed to push it past 5% utilization with lots of animations going at once).
So 48 hours later – I had managed to migrate the core functionality from a WPF.exe to a Silverlight 1.0 application – which basically involved the following :
- creation of a ASP.NET (VB) website to serve up dynamic XAML content (processed from backend rss/etc feeds)
- migration of ContentTemplates/ItemsControl WPF functionality to ASP.Net scripts.
- Conversion of Full Blown WPF XAML to Silverlight 1.0 XAML (which supports a lot less tags/attributes)
At that point I had a Silverlight App that pretty much resembled the original WPF .exe – but performed/worked a whole lot better.
The bit that I originally perceived to be the hardest/most tedious – conversion of WPF Xaml to Silverlight XAML (ie. WPF provides different layouts like Anchored, Flow, Stacked etc – Silverlight only has Canvas layouts with absolute positioning) – was actually made really really simple using Expression Blend. The ‘Convert to‘ function was the real timesaver – and allowed me to quickly convert things like StackPanels (which had no Canvas.Top/Canvas.Left values) – into Canvases. As I had severely stripped down the design+animations on the WPF .exe (in the quest to make it perform well) – there was also a lot less other conversion work (ie. <Labels> to <TextBlocks> etc etc)..
From then on in – I added a bunch of new animations/effects and layouts – as I was once again able to focus on the design/interaction (without being scared of creating a CPU + Memory hungry monster).
Silverlight – the great, the good and the bad (there’s no ugly)…
Silverlight seems to be getting a lot of press as a ‘Video Playback’ technology (and the majority of samples are based around HD video on demand) – but it’s really a whole lot more than that.. (and it’s a lot more than a ‘flash killer’ as well)…
The number one thing I love about Silverlight is it’s great performance. It’s really right up there with MCPL (Media Center) and Flash (everything else). In the past with WPF – I’d always spend the first 25% of my effort making a nice UI – and then the remaining 75% removing/enhancing bits of the UI to deal with performance issues. (a real waste of time). With Silverlight – that 75% was instead used to create new UI’s and new functionality (like the 3d team browser pictured above – which is actually 2d with smoke/mirrors – this was added for the Silverlight version – and zero effort was spent on improving performance as it worked a treat from the get-go.).
Silverlight is EVERYTHING WPF is Not…. In fact I’m now quite confused why WPF exists.. The official word is even to ‘not use it for business apps’, ‘not use it for gadgets’ – and I don’t think it was created to serve the needs of the coding4fun community. At least I have got some use out of it for Surface apps… (but have already worked out how to do all this with Silverlight – at much higher frame rate) and of course there’s of course still quite a few a lot of things you can’t do in Silverlight out of the box (like 3d etc…) – but in many of these cases there are other/better technologies (like DirectX/XNA etc).
So in a wrap on Silverlight 1.0 –
>> The Great
- Awesome Performance, Low Memory Footprint
- Awesome Video Playback performance – no NVidia issues either. (even allows WMV on a Mac!)..
- Cross Platform… see picture above of it running on the Mac…need I say more…
- Good design tools available already (Blend 1+2)
- Full Integration with HTML scripting engine (so you can interact with the Silverlight addin and catch/create events).
- Full Screen Silverlight Mode also rocks (perfect for full screen apps – ie. I’m dying to use it for some Surface and UMPC apps).
- Excellent ability to reuse skills/assets/xaml and code from existing (legacy??) WPF projects. Make migration a lot less of a headache.
>> The Good
- Works/Plays well with Vista Sidebar (32 Bit only)..
- Reduced set of tags means you spend less time going down the wrong path with layouts.
>> The Bad
- 1.0 doesn’t offer any DRM features for anything other than Video (and it’s easy to steal someone’s code, assets and XAML).
- Doesn’t work properly on Vista 64 bit (only via 32bit emulator). This means it will work in your browser – but won’t work inside a Sidebar Gadget. Unlike Flash, ActiveX etc – which can be ‘made to work’ on 64bit (by running the 32bit sidebar.exe) – Silverlight won’t work at all (which was a real pain in the butt for development).
- Reduced Tag Set means some common/well needed functionality is missing out of the box (and you instead need to custom create it from primatives). An example of this is support for Tooltips – which can be manually created by tracking MouseEnter/MouseLeave and adding a <Canvas> to handle your text display. Bits like this should have just been included in the core engine. (and as a result – you can’t actually use the ‘Tooltip’ attribute and have to find another technique to deliver the text to your client app).
- Another couple of major missing features (that could have very easily been added and not cost performance) – is scroller/flow support and alignment (ie. you can’t supply text alignment hints – you instead need calculate the rendered width and alter it’s left offset after its displayed).
- The Downloader object doesn’t support cross domain access. This is really quite a stupid/dumb decision – AFIK – the downloader is used to get Images, Fonts, XAML and other Media – not scripts (nothing that could be used for a malicious attack or not caught by the silverlight host). This means that you can’t effectively use this downloader object for mixed applications (ie. Sidebar – where assets/code is hosted locally and on a remote site). Given that you can inject images, videos, sound etc into your XAML (with no cross domain security) – it really doesn’t make a lot of sense.
- No Keyboard support in Fullscreen Mode… WHY WHY WHY???? This really kills the ability to use fullscreen Silverlight for 10 foot /remote control applications (although you could just host a browser window in kiosk mode i guess). As with the downloader object – it was stated that it was for ‘security’ reasons… ??? (would have thought the existing Silverlight/Browser security model and features would have taken care of this)..
- Basic 3d support would be really nice.. even if it was just 3d rotation of 2d planes (ie. no mesh support but ability to rotate a 2d element in 3 axis – as is provided with MCPL).
- No standalone/browserless Windowed mode (this would have been really nice to have). It could have been implemented similar to fullscreen mode (where it positions/displays itself outside the browser host) – but not taking up the full screen.
Using SilverLight for "Hybrid" Apps (Sidebar or Browser)…
As mentioned above – this app came in two flavors – a Vista 32bit sidebar gadget – and a popup Browser version.
Although the majority of the codebase/assets etc were shared between the two – some different techniques needed to be used to get it working in Sidebar.
- The main issue was that the Sidebar version had "mixed" local and remote content (where a lot of images and base XAML was preloaded into the gadget for speed) – and hence I wasn’t able to use the Downloader object to download XAML/data on the fly from a remote site.
- The Sidebar gadget was designed so that when it’s docked – you just get a HTML gadget with rotating dynamic images – and when it’s undocked – it turns into the Silverlight app. This allows it to perform a little better (when adding/removing from sidebar) as the Silverlight initialization is delayed. I also used the ‘undocked’ state for the Silverlight gadget instead of a flyout – as the flyouts close if focus is lost – and this would really screw up ability to watch video (if you checked your email etc the whole flyout what disappear).
- For performance (and faster less intrusive loading in sidebar) – the Silverlight container is actually a rectangular area in the middle with no transparency etc (the transparent bits on the edge etc are from a png background in HTML) – and the buttons/panel up the top is actually HTML only. (so the user wouldn’t have to wait for these to load). This was done due to recommendations in the Silverlight SDK that "windowless" mode may affect performance.
Anyhow – I’m looking forward to seeing some more gadgets being made with Silverlight. I’m also really excited about the potential for cross platform 10 foot, UMPC and Surface applications (ie the same areas XBAP/WPF .exe’s could have been used but didn’t perform well enough or wasn’t cross platform).
Something new I’ve been working on since early last week (a WPF based Touch/Surface App) – was shown off at TechEd New Zealand over the past couple of days. Although I couldn’t attend in person – Jay Templeton from Mabode (the company this work was performed for) - was on a stand setup in the foyer – with lots of Media Center and Plasma goodness – and has been demonstrating the new app to those passing by.
Apparently TechEd New Zealand is the second biggest TechEd in the world outside the US – with a staggering 3000+ attendees (which is pretty amazing given the small population of NZ) – so a lot of people got to check this stuff out.
The app itself is a written in WPF (Windows Presentation Foundation) – and is a cross between a Contact/Business/Media Directory and an online collaboration tool – and designed specifically to run on a whopping big plasma screen (1366×768) with special touch technology provided by Next Window. (I’m sure we officially called it something – but can’t remember what exactly – so will just call it ‘Conference Touch’).
Anyhow I thought It might be of interest to post some screenshots of it running –
Due to some of the hype surrounding Surface and iPhone – we thought it would be fun to take the app beyond being a basic touch screen kiosk – and make it do some of the neat tricks you see on the abovementioned technologies. (things like ability to slide/pull lists etc across the screen with hand motions etc).
In this screen below (the generic browsing screen) – you can pull the list left and right – and depending on how fast the pull motion was and what distance was covered – the list will slide to particular spots (or the start/end of the list).
Some other surface/touch like bits are the ability to pull down dropdown lists (so you quickly filter your data) – and also the A-Z slider down the bottom (which instantly takes you to a point in the results set based on where you touch it).
You can also drill down on records by double tapping a tile (note that these screenshots are from my own version running on my dev machine – so profile pictures etc are not loaded on – and were added dynamically during TechEd. This was made quite easy due to the great XML Data binding/filtering features in WPF )
Once you are looking at the details records above (which might be a contact, a business, a web video or even a scheduled meeting/video-conference) – you can then perform other functions (such as video chatting , scheduling a meeting and viewing a video).
Since it was a prototype as well – a number of ‘dummy’ features/screens were added to show off what would be possible (well actually the videoconferencing was one of these).
For example the login screen has ‘fudged’ fingerprinting recognition for the sign-in. (no we didn’t actually have a fingerprint reader connected – although would have been easy to implement if available).
I hear the app was well received – and maybe might show up at some other TechEd’s in the future.
I’m currently trying to get hold of a better action shot – of the app running on the stand/plasma (such as someone ‘mid-pull’ on a surface maneuver) – so will add these if I track it down (the above picture of Jay was pilfered from Darryl Burling’s blog.)
I’m somewhat confused and disappointed all at the same time – to learn that Silverlight doesn’t appear to be natively supported on Vista 64bit. (although you can run it via WOW64 layer in Internet Explorer 7).
Lack of native 64bit support means that once again - there’s no decent/clean solutions for using Silverlight for Windows Sidebar gadgets (as WOW64 doesn’t appear to be used/supported in here) – and if you try to use any of the Silverlight gadget samples out there you will get the mangled message below.
Note that as with XBAP – the loading message ignores the host dimensions – and doesn’t gracefully resize itself (to accomodate the 132 pixel wide maxmimum size provided by a docked gadget) – although at least this time you can see more of the text (with XBAP you only catch part of the first word on the loading message).
If I click through on the above ’Get Microsoft Silverlight’ message – IE is launched – and of course since Silverlight is already installed (32 bit version) – there’s nothing to download or install at that point.
Note that I also experienced similar behaviour trying to load Silverlight 1.1 Alpha in Sidebar (above sample is Silverlight 1.0).
UPDATE : I actually found a workaround/hack in this post which mentions that you can ‘kill’ the 64bit sidebar.exe process – and launch the 32 bit version instead to get all the 32bit goodness working on Vista64 (the one in the Program Files x86 folder). While this might solve some problems for the more technically minded – I can’t see it being widely implemented by the general public – so still remains an undesirable/unsupported scenario. (however maybe if someone wrote a dead-easy-to-use util that makes all the appropriate system changes and makes the 32bit version load by default – then this could be the answer?).
Silverlight – not really ‘cross platform’ (yet)….
So once again I’m pretty disappointed to learn that 64bit Vista (once again) has been treated as a second class citizen in the world of Windows Sidebar + WPF (and any other containers using similar underlying hosting technique).
So I’m going to really question use of the phrase ‘cross platform support‘ in relation to Silverlight. ie. there’s a Mac version and a 32bit windows version – so at the end of the day it’s not too disimilar to MS Office or Adobe Photoshop which allow loading of files created on either platform (and I’ve NEVER heard anyone call these products ‘cross platform’).
What I really would have liked (well expected actually) – was native Silverlight support on 64 bit Windows and PocketPC platforms. While I get the desire for Microsoft to ‘target’ Mac designers and get some Kudos in the Apple press – it’s a half baked effort (you won’t be running Expression Blend on Mac anytime soon) - Microsoft should really have worried about ‘their own back yard’ as the first point of call (ie. existing/popular o/s platforms that are out there today).
So what options are left for Sidebar Gadgets (that look like they were created this decade)….
Although ‘unsupported’ your current options for Sidebar Gadgets seem to be the following :
|Technology||Vista32 Sidebar||Vista64 Sidebar|
|Supported||(same as 32bit)|
|Loose XAML||Unsupported (but will work with slow/clunky loading experience)||(same as 32bit)|
|XBAP||Unsupported (but will work with slow/clunky loading experience). |
If used only in Flyout – user experience is somewhat cleaner (delay is relegated to the flyout).
|(same as 32bit)|
|WPF (ElementHost inside ActiveX wrapper)||Unsupported – but will work (possibly quickest way to instantiate a WPF app in Sidebar 32).||Doesn’t work (32bit ActiveX not supported in Sidebar).|
|Silverlight 1.1 Alpha|
(XAML + .NET)
|Not officially supported – but works.||Doesn’t Work (no 64bit native Silverlight 1.1 version available).|
|Flash||Not officially supported – but works.||Doesn’t Work (no 64bit native flash version available).|
Anyhow – I’m really hoping to see this whole situation changed in future (Vista SP1??) – but I’m not really holding my breath (as there are no announcements thus far indicating anything will be improved).
Microsoft have just released the Feb2007 CTP of WPF/E and given it a whole new brandname – ‘SilverLight‘. Tim Sneath has a pretty good summary of what it’s all about – and to quote Tim – SilverLight is the "next-generation, cross-platform, cross-browser web client runtime".
I’ve had a bit of a play with the new samples (SDK, Runtime) – and I’m really impressed with how fast/slick it is – with the almost instant initialization (no more long ClickOnce installs) – and its runtime performance. It’s almost like the WPF core bits weren’t used – as I’ve not seen WPF perform this well before. One really impressive sample shows how well it works with Video playback (and will incidentally bring WMV playback to Mac O/S) – and the speed at which you can jump in and out of fullscreen mode is remarkable (whilst still retaining your playback position). This also positions Silverlight to work as a nice alternative to the flash based players you currently see on youtube/soapbox.
I really hope that at some point in the future – the Blend editor can be brought into the Visual Studio IDE and provide a single place to work. This would also make sense in future if Microsoft are envisioning AJAX style applications that work with WPF/E instead of DHTML.
Some future scenarios I’m very interested in testing SilverLight technologies on are :
- Vista Sidebar Apps
- Media Center Applications
- SmartPhone Apps (fingers crossed that this will be made available for Windows Mobile – would be crazy if it wasnt).
oh .. and there’s ALSO some really spiffy looking SilverLight Wallpapers (Widescreen too) – you can download from the site ….
A couple of new updates were released for the Microsoft Expression suite last week – Microsoft Expression "Blend" Release Candidate (formerly known as Expression Interactive) – and Expression "Design" Beta 2.
Microsoft have also announced "Microsoft Expression Studio" – which gives you all 4 of the Expression products in one package (Blend, Design, Web and Media). No pricing details have been released on this as yet.
I’ve spent a bit of time with Blend of late (and have delivered projects/prototypes with Beta1 and Beta2 versions) – and it’s good to see the incramental usabilty improvements between releases. The new RC1 release however doesn’t seem to add any noticable changes/enhancements to UI itself – and instead offers a swag of brand new (and nice looking) demo/tutorial projects – and is worth a download just to see these.
I’m still stuck in two minds as to whether it’s easier/faster to edit XAML code using this product (and other visual designers) – or to just use the XAML Intellisense system which are provided from within VS2005 for raw editing (although a number of things cant ever be done with a visual designer). I guess I’m also pretty disappointed that Intellisense XAML editing didn’t make it’s way into the Blend product - something which I always assumed would be there for the final product (however given it didn’t make an appearence in the Release Candidate – its now looking unlikely).
Another thing that seems to be missing from Blend is the ability to work with XBAP projects (and although a ‘Page’ item template is provided) – you can’t seem to create an XBAP project file without VS2005. To get around this – I ended up creating a WPF Windows application – where the main Window hosted a core Page element - and then migrated the solution into an VS2005 created XBAP Solution once I was done (and this core Page element became the actual host page for the XBAP). Something I haven’t tried yet however is to initially create the XBAP solution in VS2005 and then try to open it in Blend for editing (so it’s possible this is a potential workaround – altough the versioning/clickonce layer might have issues).
These couple of omissions from Blend mean that it’s unlikely this product (or Expression suite) can be used as a ‘one stop shop’ for development for WPF – and any serious apps will still need VS2005 installed to do the hard(er) work. (unless you like coding in Notepad.exe that is).
For a current project/prototype I’m working on – I’m developing an ‘Aussie’ Sidebar Gadget for Vista – and one of the requirements/desires was to use WPF instead of DHTML/jscript. (so we can give our friends in NZ some competition - who have been blessed with a whole stack of amazingly cool gadgets for launch).
Being a glutton for punishment – and having a dangerous obsession with getting ‘Unsupported Scenarios’ up and running (WPF is not officially supported for Sidebar use) – I happily accepted this project. To make things a little more difficult for myself – I also decided I wanted to develop this on my main work machine – which happens to be running Vista 64 bit.
While I do get into all sorts of grief using 64bit (ie. Software/Drivers not working) – I still think its the best option – and as a general rule of thumb – if I get it working in 64bit – then it’s going to work in 32bit (although in some cases a specific 32bit build needs to be recompiled where 32bit specific DLL’s are used). If I did it the other way around (develop on 32bit and port to 64bit) – then I’ve got a much greater chance of finding showstopper bugs (as in most cases feature/compontent ‘X’ will be designed primarily for 32bit users and sometimes no 64bit equivelent will exist) – and would in some cases need to completely rewrite/rearchitecture parts of the program to use a different 64bit supported technique.
So anyhow in terms of my journey with WPF and Sidebar – I was luckily not the first to try this <phew> – and there was some really useful blog posts out there to get me started.
First up in the reading list were these invaluable posts from Karsten Januszewski on IRhetoric Blog :
Armed with all this useful information, examples and background – I set out to do some testing of my own.
If you check out the links above – you’ll notice there are two techniques being presented for hosting WPF’s in Sidebar – one is to host it inside an ActiveX control and expose it to the HTML page as Windows Forms User Control – and the other is to deploy the WPF as an XBAP (XAML Browser Application) and host it within an IFRAME tag (or alternatively – directly hosting a loose XAML file).
I should also mention that WPF/E is also a potential way to get WPF going in Sidebar – however since there’s no ‘code-behind’ functionality with this – I won’t consider that here.
There’s a few pro’s and con’s of using either technique mentioned above –
Cons- Doesnt appear to work on 64bit (even though Sidebar actually runs as a 64bit process). Harder to Deploy as ActiveX needs to be properly registered (if being installed locally – developer would have to right .MSIsetup package) – and hence you may not be able to package it into auto installed .gadget file. More Dev Overhead (need to create wrapper project for your ActiveX and do some additional footwork to get Class/ProgID’s all lined up)
Pros- Works on 32bit and 64bit. Easy to deploy (can just include .XBAP file in .gadget package and ClickOnce will handle the rest). Less dev overhead (no additional host ActiveX project is required). XBAP can be remotely hosted – so gives you the ability to issue updates to the end user without them needing to do anything tricky.
Cons- Slower to initialize then ActiveX (and much longer on first run). Communicating with your XBAP from your HTML/Jscript layer is very limited (unless you go to effort of writing WCF communication components).
Since I wanted to get this going on my 64bit dev machine – and also didn’t think other potential 64bit end users should be prevented from using this gadget – I decided to go down the XBAP path. It also made sense to have some easy/automatic mechanism available to seemlessly update the XBAP if new versions were created (via ClickOnce).
Some of the downsides of using XBAP’s are mentioned in Karsten’s posts above – and are mainly due to some unsavoury and clunky behaviour experienced when you add/remove the gadget to sidebar (and also reported to cause issues when you start up or shut down the machine once its added). This is partly due to background dlls being loaded for WPF (PresentationHost etc) – which can put a strain on your system when its busy doing something else (such as starting up your desktop after logging in).
Additionally – one downside of XBAP was that when initializing the gadget in the ‘docked’ area in Sidebar (which is 130px wide) – the XBAP ClickOnce screen looks pretty unreadable.
Using WPF only the flyout also had a number of upsides – and with XBAP’s – it solved a number of the issues mentioned above –
- Because the gadget doesn’t display its flyout (the WPF bit) when added/removed from Sidebar (or when machine is shutdown or started) – the WPF PresentationHost doesn’t need to be initialized/unloaded at critical times. (and hence eliminates the ‘glitch’ factors).
- When you do launch the flyout window (by interacting with the docked gadget) – the system is generally in a ‘less’ critical state and it can be loaded cleanly and quickly. (and similarly the flyout can be closed quickly).
- If it’s being loaded for the first time by ClickOnce deployment (or updated) – then the flyout window is large enough to see the progress/status dialog. (as opposed to this screen being garbled in the docked gadget).
So anyhow I’m sticking with this technique (‘XBap on the flyout’) – and hope I don’t find any issues as I get closer to finishing this. (but so far so good!).
One hurdle I encountered along the way – was that initially I couldn’t get it going on my development machine. Normally I run Sidebar on my 2nd (2 of 3) monitor – and when the flyout was launched – the Xbap didn’t appear. I noticed however that if I immediately played a Video within the XBAP – then I could actually here it (just not see it).
Chuck Sterling came to the rescue and pointed out that this was likely a ‘rendering’ issue – and that he’d had similar problem with a NVidia 7300GS based machine. So a little while later I thought I’d try running Sidebar via my primary monitor (as some other applications sometimes had issues on all but my primary monitor) - and low and behold it all worked (so very much indicates something going amiss with the graphics drivers). I do have the latest NVidia drivers from Windows Update (which appear to have this issue) – at least this is something that might be fixed in future driver updates.
So now I’m up and running and it’s full steam ahead on this WPF gadget (and now concentrating on the content and not the host) – and it’s starting to look very cool and very ‘you cant do that in DHTML’ish. Hopefully it’s smooth sailing from here.
I’d still like to learn how to do ActiveX/WPF on 64bit Sidebar (because it might be very useful for other scenarios) – but that adventure will be best left for another project.
If you’re watching the WPF blogs you might be seeing hints that something incredibly important is going to be announced tomorrow afternoon on the WPF 3D Team blog. This is possibly the most exciting announcement related to the 3D features in the WPF since… well, since we’ve announced WPF was going to have 3D features!
I’m going to take a punt on what it is… (don’t go starting any roumors now – this is just speculation)..
a) I think it’s an announcement that the cool 3D functionality from DX10 will be directly supported (ie reflections, shaders, shadows, bump mapping etc etc). Currently in WPF 3D - a ‘DX7 like’ feature set is being supported – so this would really be huge.
b) Another guess (if the above is wrong) – is that a whole additional swag of WPF 3D functionality is going to be opened up specifically for WPF/E.
c) and a ‘just in case’ guess. Microsoft are going to announce they are releasing a new tool in the Expression Suite that is focused on 3D (ie something like Zam3D but done with the same rendering technology) – and maybe even works with XNA as well..?
and then again I might be completely wrong…
The announcement might be already out by the time you read this – so try the links above.
<EDIT time="the next day">
Ok well I was totally wrong on all three guesses (bummer)!…
The announcement actually was… (drumroll) … that they have now made it possible to properly use the standard 2d controls in 3d scenes (ie you can have a textbox or slider displayed inside a 3D scene – such as wrapping it around a sphere – and it now responds to all the input methods like keyboard/mouse etc). In the past – you had to do some fancy 3d hittests etc (and write callback handlers) – in order to do anything like this (so this new ’feature’ saves a whole stack of code/pain if you are using 3D).
What’s nice about this announcement is that the have done it using the same core engine – and just extended some of the existing Viewport3D classes (which shows off just how extensible WPF is). Anyhow – go check the links above to read all about it..
Although this is all very cool stuff – I can’t help feel the anti-climax – and think they overhyped it just a little too much. (and I was expecting something a little Bigger)..