I have a problem with my WPF application using the Intel HD video cards. The application crashes at starting time with a NullReferenceException within the PresentationCore.ni.dll - the system dll. With ATI HD video cards it works without problems.
Just a guess, but this seems to be a driver problem. You can try software rendering to avoid using hardware acceleration.
Related
I recently installed VC++ 6.0 on an old machine with Windows 95. On Windows 95 there is a 3D maze screensaver made with OpenGL but the computer doesn't have a 3D video card. I would like to know how I can make 3D graphics like in the 3D maze for no 3D video cards.
If you know of a good tutorial or book, I would be happy with your suggestion.
OpenGL, if no dedicated 3D hardware is available, can render the graphics on the CPU. You might have noticed that, while the screensaver is running, CPU usage gets pretty high.
If you want to learn more about OpenGL, the I would recommend that you take a look at https://stackoverflow.com/q/62540/1103747.
My personal favorite is the OpenGL Superbible. But as a suggestion, if you want to learn 3D graphics and your target OS is Windows, I think that you should study something else (WPF, DirectX, XNA, etc). Obviously you will probably want to upgrade from Windows 95.
Many 3D games were written with graphics provided by software. Both Open GL and Direct 3D have modes that allow for software rendering.
The original version of Half Life can run without graphics hardware and this was one of the reasons for its success.
Back when Windows 95 was current, very few machines had graphics cards with 3D accelerators and so this was how PC games worked.
The demo is actually a raycaster. It's the same tech that is used in Wolfenstein, and Doom 1/2.
More info here: http://en.wikipedia.org/wiki/Ray_casting
I'm experiencing a GUI freeze problem, related to hard vs. software UI rendering.
The context : 2 WPF apps (.NET 3.5 SP1) running on a dual-display XP Embedded machine (DirectX 9.0c).
At some point, one of these app freezes. But only the rendering : the GUI stays active (message pump is active, the application is responsive), but the rendering is not done.
The freeze can last seconds or forever.
The 2nd app keeps running normally. The bug occurs only in a dual-display configuration, the 2nd app being a kind of catalyst (more memory and CPU usage...)
Using Perforator, I see that Video Memory Usage is continuously going up & down in spikes (cf : screenshot).
During that time, one native thread is consuming 100% of a CPU (the stack-trace involves WPFgfx, DirectX, GDI, and video driver)
Usually, when the app unfreeze, it's fully software rendered (purple tint with Perforator).
Also, de-activating hardware rendering unfreeze the app.
My conclusion, so far, is that I'm facing an out of video memory (as described at point #14 in this post), with an attempt to fallback to software rendering, but there is a loop somewhere trying again in hardware mode.
Am i right ?
Would it be more a WPF problem, or a video driver problem ? or even DirectX ?
Are there some parameters I can tune around this ?
Am i right ? Would it be more a WPF problem, or a video driver problem ? or even DirectX ? Are there some parameters I can tune around this ?
This sounds like a driver issue. I would start with seeing if there are driver updates. The best option might just be to disable hardware acceleration altogether, as WPF (on XP especially) really relies on the graphics drivers.
Visual Studio 2010 sp1 disabled hardware acceleration for itself on XP for exactly this reason...
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.