Poor StackPanel performance with WPF - c#

I have an application which runs fullscreen on a high resolution display (1920x1080).
About 25% of the screen is a StackPanel that scrolls images across the screen.
(the X position is animated with double animation)
The scroll is very laggy and jumpy, and with visible tearing.
This is running on a brand new high-end gaming laptop, running Win7 64bit.
I don't understand why the performance is so poor. Am I doing something wrong? Does this kind of animation run on the CPU or GPU? Is there a smarter way to scroll images across the screen?

WPF can be hardware-accelerated, but only on newer video card drivers. Some of the onboard, out of box drivers, will default back to software rendering, which can feel really slow and clunky. As for the tearing, that's a normal video card setting, called V-Sync. I would try updating the video card drivers to a proprietary driver (nVidia, AMD, etc.), and enabling vertical sync on the card.
You can check to see if it falls into software, or hardware rendering using the methods explained here.
If that doesn't resolve the issue, the only other possibility I can think of is your animation/rendering is not synced to the GUI.
See this msdn article for more details.

A trick that I've seen that can get around this issue is to place a 3D object on your page, view it side on and rotate it e.g. for 4 images have a cube with an image set to each side.
Yes the rotation still requires GPU and processor time but it is taken care of internally by the WPF animation and so doesn't require interaction with code behind once set rolling.

Related

CPU Throttling Issues with WPF

I am working on an application in WPF using Vlc.DotNet. I was having an issue with the video playing back with a terrible frame rate on my laptop.
After some research I identified that the issue is related to the CPU throttling down. If the laptop power profile is in BatterySaver mode it has the issue. If I switch it to performance, everything works fine. It seems to me like in BatterySaver mode it allows the processor to throttle down, and for some reason doesn't throttle back up correctly when the application needs it to. Is there anyway I can fix this issue?
I tried setting the priority with the code below and it didn't seem to make a difference.
System.Diagnostics.Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
Vlc.DotNet updates and ImageSource with the next rendered image. I have this source bound to an Image on the GUI that displays it. I used the WPF Performance Kit and can see what is happening, but not why. As soon as it starts playing, AKA updating the image on the GUI at 30fps, the frame rate of the entire application drops down to around 5fps.
Have you tried switching to software rendering to avoid the bottleneck of CPU power downs? I know WPF uses a separate thread for rendering and I'm not sure if you can even access it from Process.Threads. What I've done in the past is attach to the power mode changed event and switched the mode dynamically like this so power mode changes don't switch to hardware rendering. Not sure if this will work as I don't what your specific bottleneck is, but hopefully this points you in a good direction.

WPF application, fonts graphical error

I have application in C# WPF (.NET4, app runs on Windows XP Embedded) and it worked correct, but now I received screenshot and there are graphical errors around text. These errors are only around text, not button edge, nor Windows desktop.
Images:
It is graphical error (hardware), or program error which can be repaired?
Try using:
TextOptions.TextFormattingMode="Display"
Which should use ClearType. Or you could try:
TextOptions.TextRenderingMode="Aliased"
..and see if you get better results
WPF should try to use ClearType and anti-aliasing by default to give a smoothed look out of the box. It cannot be turned off WPF Anti aliasing workaround.
There's a lot going on behind anti-aliasing, like sub-pixel anti-aliasing. http://blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx. Edges are often aliased with another algorithm, that is hardware accelerated too: edge anti-aliasing. That maybe the reason you don't have problems with edges. For performance purposes the system tries to be smart and use hardware acceleration (all modern GPUs provide such). The thing what you develop is for some kind of commercial touch screen device seemingly: like electronic information booth at plaza/mall, or some control terminal in a factory, or something. These usually can have weirdo hardware in them, exotic GPUs and motherboards. Vibration and environment impact (hot day - cold night temperature change recurrence) can cause them to have glitches and hardware failures.
Try to run other software too on the device, which uses ClearType anti-aliasing like WPF does also. See if only your software causes that or not. See if other WPF software causes such.
You can try to turn off hardware acceleration if you can on that system, and see if software rendering improves anything.
http://blogs.msdn.com/b/text/archive/2006/10/18/tips-for-improving-your-wpf-text-rendering-experience.aspx
Poke around in settings also.
Try to run hardware diagnostics and GPU tests, depending on what you can get to the device.
I would rule out font file corruption: that would probably make the font completely unusable, and you also report that the weird look comes with other fonts too, I don't think that all of them is corrupted. Try to run diagnostics for software error though.
Are there any effects being applied to the text? I've seen instances where a DropShadowEffect is applied to text - this renders well on some hardware, but on other users' machines, the text looked mangled. With the drop shadow removed it rendered nicely.
See, for example, http://social.msdn.microsoft.com/Forums/vstudio/en-US/f44bce57-d67f-46d3-8161-57c80a02e893/strange-blurring-issue-when-using-shader-effect?forum=wpf

Dynamically increasing/decreasing speed of a video in a windows forms application

I'm building a Windows Forms application in VS 2010 that smoothly increases or decreases the speed of a video playing back based on the speed of the user input.
I've tried several avenues..
1.) Using the AudioVideoPlayback DirectX class - I set the speed of the video, by setting the current position of the video, based on a timer.. and increased or decreased that value based on user input. While this worked on my PC, it lags a lot on our lower end target PC's. Can anyone think of a more efficient way to increase/decrease the speed of playback using this class?
2.) I've tried the Windows Media Player ActiveX control, and tried setting the rate/position dynamically, but this is extremely jumpy and laggy even on my development PC
3.) I've tried the Apple QuickTime Control 2.0 COM Component that comes with VS 2010, and it's also very laggy.
4.) I'm trying to figure out how to set the speed on the Shockwave Flash Object control, but haven't found that out yet
Can anyone suggest other avenues to explore? I just need to be able to increase/decrease the speed of video playback smoothly based on user input without lag. I don't care what format the video needs to be in, all videos can be converted to the required format.
Any help/ideas will be appreciated.
Thanks
The ultimate way is to decode the Bitmaps from videos, and handle the frames yourself.
Try the CaptureNET example from DirectShow.NET. It allows you to capture bitmaps from each frame. After that, write your own playback control to handle the refresh rate.
After trying many different formats/libraries and components I found the VLC Media Player ActiveX control to be the most efficient method to slow down/speed up video without any noticeable lag.

Is WPF the reason my application is slow?

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?
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!)).
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
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.
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.
Avoid Panel with Single Child. Try to reduce Visual Hierarchy.
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.
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.
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.
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

WPF video tearing on Windows XP

I've created a WPF application using C# that renders about 50 3D elements and animates the camera in order to move around the scene.
While it all works, I've noticed as the camera moves, ugly video tearing occurs.
I'm well aware of the standard cause of tearing, ie the application is updating frames at a different rate from the monitor/adapter vertical sync.
I've also read that the default screen update rate in WPF is 60 frames per second and that on XP WPF updates without regard to the montior v-sync.
For certain scenes the tearing is less noticeable, but often it is distracting enough to be a real problem.
I'm really hoping there is a resolution, after all Windows Forms has had double buffering for years. Moving to WPF is actally a backward step for many types of application if there is no resolution.
So, on Windows XP, how can I configure WPF to remove tearing?
I'm looking for more helpful answers then "move to Vista". This is simply out of the question for many of the future users of this application.
No answers yet, surely with the number of WPF developers out there someone else has seen this problem?
In the meantime I've investigated/read some more and have come across the Timeline.DesiredFrameRate property.
With my display running at 50hz vertical refresh I tried setting this to 50 FPS in the hope this would brings things in sync. Unfortunately this had no effect on the tearing.
However, I did have to apply it to a single specific animation I created (in code) using BeginAnimation(). I'm not sure how this would affect a "global" framerate at all.
Instead, I would have expected to need to do this at a more global level, say on the viewport, however I couldn't find DesiredFramerate property on the viewport object.
Another area to look at could be the RenderCapability.Tier but I haven't had the time to look in detail yet.
[Update]
No solution but a useful tip. To set the DesiredFramerate globally (ie for all animations in the viewport) you can override the PropertyMetadata for the
Timeline.DesiredFrameRateProperty dependency property:
// Set the global desired framerate to 50 frames per second
Startup += delegate(object sender, StartupEventArgs e)
{
Timeline.DesiredFrameRateProperty.OverrideMetadata(typeof(Timeline),
new PropertyMetadata(50));
};
It's best to place this in the constructor of the standard WPF Application class.
Unfortunately this didn't solve my problem because even setting it to FPS, it must not be synced accurately enough with monitor v-sync.
It is handy to know about though, particularly if you have slow moving animations and want to save CPU usage by setting the FPS much lower then the default 60fps.
[Update]
Setting the DesireFrameRate to some very high value such as 100+ seems to reduce but not remove the flicker. One big drawback however is that the CPU (on my 4 yo PC) goes to 35%.

Categories