15

I am developing an application using WPF. The app runs full screen, and I need it to resize nicely no matter the monitor resolution. The graphic designer has designed beautiful images for the UI buttons, backgrounds, etc. Using an Illustrator plug-in, all the images have been converted to xaml files. I've added all these images into the application, and they look great. I am also using a lot of Grid layouts so that the screen can resize while still maintain the layout. All of this is displaying as desired, nothing looks stretched when run at a different resolution. However, screen transitions and UI interaction are slow.

I am wondering, is this is due to the heavy use of graphics? Am I using too many Grid layouts? But, I need the Grids so that I can have resolution independence.

The application runs fine on my development machine, but is very noticeably slower on machine with lower performance capabilities. Yeah, this is to be expected, but not to the degree that I'm seeing. My employer insists the application runs smoothly on these lower performance machines.

I've done some profiling of the application and it seem that what takes the most time is the display stuff (though I'm not sure I fully understand how effectively to use a profiler).

If it is the WPF that is causing the slowdown, what can I do to improve this?

Dan Vogel
  • 3,858
  • 7
  • 41
  • 57
  • 1
    Don't know enough about it to write up a real answer, but I'd look carefully into the output of the illsutrator-to-xaml plugin. At the very least see what your app behaves like with placeholder graphical elements (eg, an empty grid). – Egor Dec 12 '09 at 01:23
  • Did you fix this? I'm having the same issue. What was the solution? – Luke101 Jun 30 '22 at 17:16

6 Answers6

12

You can drill into which WPF activities are using up time using the Performance Profiling Tools for WPF. Assuming a heavy graphical load is causing the slowdown, this should give you some help as to what might need to be simplified (e.g. layouts) or removed (e.g. bitmap effects (these are a classic perf killer, though I don't want to prejudice your profiling!)).

itowlson
  • 73,686
  • 17
  • 161
  • 157
5

If it is the WPF that is causing the slowdown

Probably not ;)

It is much more likely that it is your code that causes the slowdown. WPF is powerful, but you have to understand the core concepts to make it work well... You should have a look at this video from a PDC session, it provides lots of advice on how to make your WPF application faster

Thomas Levesque
  • 286,951
  • 70
  • 623
  • 758
  • 1
    This seems to be the current location for that video: https://channel9.msdn.com/Events/PDC/PDC09/CL10 – TripleAntigen Apr 25 '16 at 02:03
  • 3
    imo this answer is without base or substance. Sure WPF is powerful, but that power doesn't come without overhead(s). It wouldn't be a stretch of the imagination to say that perhaps the lower end machines of the clients don't meet the min/rec spec for WPF. The real answer here is to profile the application - only then can an objective decision be made as to next steps. – LintfordPickle Nov 27 '19 at 07:15
4

  1. Convert your XAML Vector Images of buttons into Transparent PNG Images. Path and Shapes are very heavy to render, calculate and resize. Mostly after deployment, the images never change its better to have them as raster then vector, unless you want to perform smooth animation of changing shape, size or other attributes.

  2. Grids are very costly layout managers as compared to Canvas, DockPanel. You can certainly think of replacing certain grids with DockPanel sometimes, but yes its not an easy fix it requires lot of brainstorming.

  3. Avoid Panel with Single Child. Try to reduce Visual Hierarchy.

  4. Use more of fixed size for buttons and such small elements, if you specify fixed sizes of children, it becomes easy for Panels to do layout processing.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
  • 3
    PNG images wont resize nicely, that's why I've gone with vectors. – Dan Vogel Dec 14 '09 at 17:51
  • 3
    Plus, how do I develop an app that will adjust the layout to fit the screen resolution unless I rely on Grids? – Dan Vogel Dec 14 '09 at 20:24
  • Not all images needs to be in PNG, for example all icons, of buttons or like the one on back/forward buttons of IE, they always remain same even if you resize, such buttons can be converted into PNG. You can use DockPanel instead of grid OR use relative column/row sizes instead of "Auto". If you can show screen of your app a little bit, I can then suggest some better steps. – Akash Kava Dec 15 '09 at 08:15
4

In general, WPF is perfoming much worse in drawing performance than Windows Forms, and native GDI or DirectX.

Yes, WPF is powerful in the sense you might make some neat stuff that is not supported in GDI, but it is more sluggish.

If you are having much drawing to do, and you want to support it on slow hardware, then WPF is not a good choice.

oystein
  • 41
  • 1
1

WPF performance depends heavily on the quality of the video card in the machine more that the processor/memory. Bad video card = bad WPF performance.

eduesing
  • 351
  • 1
  • 5
1

Well, this is a long shot: when I installed VSTS 2010 (and it uses WPF) it was very slow on a Windows 2008 server with enough CPU/memory, and very fast in a more modest notebook. We managed to disable hardware acceleration and it became notably fast into that machine.

Maybe you do want to try this configuration, as it is very simple: Visual Studio 2010 Beta 2 editor performance fix running on a virtual machine

Rubens Farias
  • 57,174
  • 8
  • 131
  • 162
  • Interesting, never seen DisableHWAcceleration used to speed WPF up before! – itowlson Dec 12 '09 at 01:10
  • That made me think too.. but worked on VS2010, I swear =) http://stackoverflow.com/questions/1743525/can-i-and-how-do-i-target-net-4-with-vs-2008/1743556#1743556 – Rubens Farias Dec 12 '09 at 01:21