12

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!

Bjorn
  • 161
  • 1
  • 6
  • I don´t know if this helps: Could you try to update de video driver with latest version, DirectX, and try to install .Net 4 (maybe it solves some bug, and makes some update, even if you are running .net 3.5), and Win7 to see if it has better performance on this device? – Tony Jan 29 '11 at 12:48
  • Thanks for the driver comment. We have tried both the Intel XP GMA 500 driver as well as the IEGD driver. Both have similar performance. However we did find great OpenGL performance with the IEGD driver. – Bjorn Feb 21 '11 at 22:15
  • I have heard that Intel claims the GMA 500 driver has a WPF specific bug that they are not planning to fix. I've also heard that the GMA 500 pipeline is too small for WPF because WPF does all screen layouts on the graphics pipeline. GMA 500 is expecting only 3D workload and can't keep up with responsibility for all screen rendering. – Bjorn Feb 21 '11 at 22:18
  • Do yu maybe have a source for the first statement? Thanks! =) – Jens Mar 29 '11 at 06:28

3 Answers3

2

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.

Ben Schoepke
  • 789
  • 2
  • 7
  • 17
  • We are running .NET 3.5 SP1 on Windows Embedded Standard 2009. – Bjorn Feb 21 '11 at 22:11
  • The most basic issue we have are screen to screen transitions. Layout and render of basic screens (TextBlock, Label, TextBox, Button, Grid) takes over 1 second. – Bjorn Feb 21 '11 at 22:13
2

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.

Jippers
  • 2,635
  • 5
  • 37
  • 58
1

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.

Rob Perkins
  • 3,088
  • 1
  • 30
  • 51
  • "Low performance" integrated graphic solutions have pretty much always been around :-] However, it is true that WPF was designed for a hardware stack with some sort of performance. On a related note, the host environment and any pass-through (e.g. GDI<->DX, if used) can make a huge difference. I think windows 7 fixed some of the extra long pipeline issues. –  Jan 29 '11 at 07:32
  • They have, that's true, but Microsoft's Avalon (later WPF) people didn't target them; they moved almost immediately to offering Silverlight for a lightweight solution. – Rob Perkins Jan 29 '11 at 20:10
  • Thanks for the Silverlight recommendation. Our project is committed to WPF at this point and do not have the option to switch at this time. – Bjorn Feb 21 '11 at 22:11