Kevin Hoffman this morning reports that:
When put under a virtual machine
running Windows 7, VS2010 fails to
render things, borders disappear,
windows become unusable and the
experience is downright awful. On the
other hand, when you run VS2010 "bare
metal" with no virtualization between
it and your video card, everything is
beautiful and all works well.
What about a virtual machine would cause VS2010's WPF to render poorly?
WPF renders stuff on a Direct3D surface. It's able to take advantage of hardware acceleration features provided by graphics cards to improve performance. Under VMs, these features might be unavailable.
I haven't tried VS2010 specifically yet, but you may be hitting a known issue with WPF apps in VMs. Try disabling hardware acceleration as described here:
http://msdn.microsoft.com/en-us/library/aa970912.aspx
Our custom WPF app running on a VM had similar performance problems, and that fixed it for us.
As Mehrdad says, Virtual Machines don't really virtualize 3D hardware (there is some work being done in this area by VMWare, but it's only older versions of DirectX I think) and WPF utilizes the GPU to render more efficiently, thus it has to use software to render in a virtual machine and that is significantly slower.
If you have a multi-core machine, and you're using a Virtual Machine manager that supports giving VM's multiple cores, then you might consider adding more cores to the VM to better utilize CPU resources, or use Kevin's Registry changes.
VS2010 isn't a finished product and it ties in quite heavily with various elements of the system's native GUI interfaces (which, in Windows 7, also not a finished product, these are not fully cultivated). It's not entirely surprising that two betas running in a virtualised environment would have issues. As stated, this is liable to be an Aero issue, which ties in heavily with DirectX's hardware rendering. These issues might not occur under classic assuming Win7 has that.
I'm using Windows 7 + VS 2010 + WPF and everything is fine, however I'm using VMWare Fusion with hardware acceleration on.
Related
I've been developing a windows store application for a windows 8 tablet (Microsoft surface). So far the application has been designed using XAML-RT/C# using a SQLite database. The application won't be released via the store, it'll be just used internally by my company.
I am however finding numerous problems with the platform. i.e. speed of the surface device, releasing versions and renewing the developer licences.
As the application is still in the development stage and no decision has been made on the final tablet I'm thinking about re-writing the application using WPF and using a full windows 8 tablet (not a RT/ARM version). This way I can use full SQL and have much more control over releasing the software.
So, my question is...
What is generally the best development platform for a full windows 8 tablet? Is it best to go with WPF or stick with the Xaml for RT?
Thanks
WPF
less sandbox limitations (can call any APIs)
is currently somewhat easier to do enterprise deployment with
has more features
is more mature overall
can benefit from Surface SDK 2.0 controls for great touch support on big screens
WinRT/XAML
works on ARM devices
is lighter and faster
has built-in modern touch-enabled controls targeted for tablet use
might be better suited for use on tablets overall
Overall the main benefit of WinRT is that you can use it on ARM tablets which are cheaper, lighter and more usable as tablets. WPF requires heavier devices and might be slower, but you gain the ability to access all legacy APIs.
If you intend it to be fully touch screen ready then you'll have to do some extra work in WPF to get the level of UI interactivity that you get from the "metro" apps.
That being said, if you're writing a complex application that requires lots of API calls/web services and file handling then you're going to have a much easier time with WPF.
I thought about converting an application of mine from WPF 4 to Silverlight 4. One of my reasons was the impression that Silverlight as subset of .Net 4 should need less computer resources so it would run better on netbooks. I checked this and was surprised to see that the minimum system requirements are even higher:
WPF: "Pentium 1 GHz or higher with 512 MB RAM or more"
Silverlight: X86 or x64 1.6-gigahertz (GHz) or higher processor with 512-MB of RAM
Does this resemble your experiences? Do I really have to fear that my app will run slower if I do the conversion to Silverlight?
Thanks in advance.
This matches my experiences.
Silverlight is often not as optimized as WPF. Part of this is the runtime - the runtime is not quite as mature as the full desktop CLR, and part of this is the optimizations available. That being said, every version of Silverlight is improving its performance characteristics...
The largest problem in my experience is that silverlight doesn't fully utilizy your graphics adapter (since it must be able to run inside a browser sandboxed).
Well, I haven't benchmarked anything of the sort, but I can reflect on theory.
Silverlight is sandboxed, WPF is not. The sandboxing has a cost (at the very least lots of extra checks to throw SecurityException).
Silverlight is made to run inside a browser, using a plug-in. WPF is made to run on the desktop, using the naked framework.
WPF was designed to 'replace' full native apps, so must be very optimized. Silverlight was designed to extend the web, which is not so responsive to begin with.
So, my guess is: yes, Silverlight is a bit slower.
My team is developing WPF applications to be deployed on an Intel Atom Z530 netbook hardware platform. The Intel Atom Z530 comes with Intel GMA 500 integrated graphics, which has a PowerVR SGX 535 GPU core. The PowerVR SGX 535 GPU core is the exact graphics core used in Apple's A4 chip set for the iPad.
My question:
Why is WPF so slow with PowerVR SGX 535 graphics?
We actually turn hardware acceleration off for our WPF application to get better performance (screen to screen transitions, dialog transitions, 2D graphics interaction). The iPad technology stack is able to achieve much better UI performance with the same hardware graphics core.
Thank you for any insights!
Are you running .Net 4 on Windows Embedded Standard 7? I've found that WPF runs much better in Windows 7 than XP.
What are your specific performance problems?
If it's animation, try using cached composition (.Net 4 feature) to apply a BitmapCache to any background that you may be animated things over. Also, make sure to share and freeze all the brushes you use.
If it's charting, drop down to DrawingVisuals instead of using Shapes or other higher level contstructs. You can also use GDI+ to draw into WriteableBitmaps as a last resort.
Also, dual-core Atoms will also provide a significantly smoother WPF UI in my experience. Try an Atom D510 or D525 if possible. They use much more power and give off more heat but the user experience improvement was worth it for my product.
And keep in mind that iOS apps are native code. WPF provides a much higher level of abstraction and much faster development at the expense of generally slower performance, especially when hardware resources are limited.
I've found that all GMA chipsets on XP have terrible WPF performance. Not only low framerates but terrible graphical glitching and artifacting. Surfaces will become see through, video surfaces become a garbled mess, mouse overs will become glitchy.
Our solution has been to disable hardware acceleration via a registry patch that we offer customers that have issues.
I'm almost certain that Atom processors with those graphics were never even considered when WPF was in its design and first implementation phases. WPF was in development over five years ago, long before GMA 500 graphics were around.
You may have better results with the Silverlight 4 stack, which was certainly designed for lightweight environments. Much of what is possible in WPF is similar or identical in Silverlight. If you're not using WPF's 3D graphics or any of the other features, you may be able to get an easy port of the XAML, at least.
Last week I learned that Silverlight on the Windows Phone uses a "compositor" thread to cache bitmaps and animations and run them independent of the UI thread. This allows animations to run smoothly even if the UI thread becomes blocked.
My question is: why was this introduced only for WP7, and not Silverlight (web) or WPF?
A lot of Microsoft's recent focus has been on Silverlight for Windows Phone 7 (make or break time), so they have added essential features to the phone now that would be in the next version of Silverlight. Basically anything to make the phone look fast/smooth/good.
I heard specific mention of an upcoming feature in Silverlight (browser version) being: "running animation storyboards on a background thread". That was in a recent video (sorry lost the link).
To have the compositor thread specifically run on a GPU requires that the hardware running the software has a GPU and that it is sufficicently powerful for the task.
WP7 devices are the first place that they can guarantee that every piece of hardware running Silverlight has a baseline hardware requirement.
If Silverlight tried to do this it would have to move the compositor on to the CPU if the hardware it was running on didn't have a GPU. If that CPU was a single core then on some machines the underlying code would just have become more complicated for no performance gain.
The compositor (render) thread runs the GPU on Windows Phone 7 devices.
As a resource constrained device, it's necessary to do all the cool animations to have this stuff running on the GPU with bitmap cached images. I would imagine this was an unavoidable design choice for the Windows Phone 7 platform team to accomplish the kind of visuals that are possible on Windows Phone 7 devices.
Sure, perhaps it will also be relevant to do for WPF and Silverlight in general in due course.
So it's not so much about providing another thread to alleviate load from the CPU. It's a thread to manage the GPU. The UI thread runs on the CPU, handling general UI interaction and all other non-GPU code.
I'm maintaing a Windows Forms application which draws map data with overlays. I've been considering a move to WPF for the drawing layer, to take advantage of the graphics card rendering. In the last couple of weeks, however, I've started to have some doubts:
The new release of Evernote uses WPF, and doesn't run on Nvidia Quadro cards.
A WPF transitions demo from WindowsClient.net stopped rendering part-way through the animations on one of our test portables with Intel graphics (and yes, we had the latest Intel drivers).
Stack Overflow questions like this.
With the current Windows Forms codebase I can expect the application to run identically at every installation. WPF is much more dependent on the quality of the graphics card drivers, and I don't have the testing resources for comprehensive coverage.
I'm particularly interested to hear from people who've delivered a WPF application outside their own company or to a mixed population of machines - did hardware and driver specific bugs cause you a significant support burden?
We are facing some issues with the drivers of a specific graphic card vendor. Blue screens, a diagonal pixel displacement and application crashes have been observed. It is possible, however, to turn off the Hardware Acceleration on a per-application basis. Sad but true, this is the current workaround.
As already stated, I hope that the VS2010 release will help to improve the stability. Perhaps one day we'll see lists of WPF related fixes in the release notes of graphic card drivers. Along with the latest fixes for the game engine XYZ.
Our WPF application is running on Windows XP SP2 (minimum) and is ok apart from on some machines, if the application is running and the PC goes into screensave mode it blue screens and crashes the machine. This seems to be graphics card driver version related - some of our users run dual monitors.
We haven't cracked this issue yet.
WPF uses Direct3D for its rendering, falling over to software if necessary. My best guess is that some drivers say that they support something in hardware but really don't handle it properly, and that is when we see these incompatibility issues.
The answer to your question depends on how willing you are to have less compatibility with machines than your current codebase has. If you've ever visited support forums for PC games you see all sorts of threads about graphics problems. As most PC's are going to be more and more compatible with Vista/Win7 and therefore support D3D9/10, the issues should lessen. The real question is if the tradeoff for you is worth it.
My own experience deploying a WPF app, I had issues with the mediaelement not working the same on two very similar PC's. But the video subsystem is a different can of worms anyway. Otherwise it was fine but I wasn't doing anything special graphically, just standard xaml.