I ran into a problem with my GUI.
My GUI has multiple parts in it.
The first one is for an image (from 500x500 to 3000x3000 and it has to update up to 4 times each seconds)
The second one is the main menu
The third one has buttons with options regarding the image. I am not showing all of them at once, I scroll through several menus and i render only the ones who are visible. (An example for the otpions is the pixelsize of the image)
I display the image inside a Viewbox which is 800x800px big. I stretch the image inside of the box with Stretch="{Binding Path=StretchMode}"
The Image I get is some kind of stream. I get multiple Images each second.
Now when I display an image, the first GUI part works fine (regardless of the image size) but the others sometimes have a heavy framedrop. I will give some examples:
Example 1:
The image is 500x500 pixel big. I can work without a framedrop and the whole gui updates correctly.
Example 2:
The image is 1500x1500 pixel big. I can work without a Framedrop and the whole gui updates correctly.
Example 3:
The image is 2500x2500 pixel big. The Image updates fast but the rest of the GUI have framedrop from 60 fps to fps and sometimes even to 1 fps.
My thoughts about this problem were:
Hardware is at its limit. But a look on the Taskmanager and CPU/RAM analysis with Visual Studios says it is allright.
It is too much to render for the GUI because 3000x3000 is big and 4 times each seconds is not slow either. After a test with loaded (I loaded them from a hdd-drive) 3000x3000 images (Same Datatype) it worked fast and without problems.
Too much changes of the GUI at once. I tried the Software with only 5 updates. Still the same problem.
Microsoft Prism event not occuring. This wasn't it either because it comes inside the Controller and is Raising the changes if there is a change. (I have a logger which writes logfiles and it is raising the Change event more than the GUI is really changing)
Usage of a different datatype. Possible but i tried out several. (BitmapSource, BitmapImage and WriteableBitmap)
Outsourcing some rendering options in another thread. Still no change.
I hope you can give me some ideas why the GUI has this behaviour.
If you need code, please tell me.
I am not using a VM.
The problem occurs on Windows 7 64 bit and Windows 8.1 64 bit (not testet on Windows 10)
My hardware differs. The problem appears on my laptop (Intel i7-4702MQ #2.2 Ghz, 8 gb ddr ram, intel board graphics) and on workpc's with different specs (the highest are: Intel Xeon with 3.5 Ghz, 128 GB DDR4 Ram and a Titan X and a 4k Monitor)
EDIT: Apologies, stack doesn't have my score high enough to comment, so comment-ish content here instead.
EDIT1: Process explorer (from Sysinternals) should be used perhaps as a low-hanging fruit to see what (if any) video resources have a high consumption. there is a tab/area in process explorer for looking at graphic resources. In process explorer you can do a 'select columns' and add GPU resources for easy viewing. Might be a good angle to try.
I would venture a guess at this point that we are dealing with a
An ETW trace with DPC data might be helpful. Also you don't mention if you are in a VM or not, a VM would make taskmanager reflect inaccurate resource consumption on CPU.
An example of how to collect such a trace is here: https://blogs.technet.microsoft.com/jeff_stokes/2012/09/18/how-to-collect-a-trace-for-audio-or-video-problems-in-windows-7/
In any event, I suspect you are looking at kernel drivers or IPC/DPC issues rather than just raw CPU consumption here. More data needs to be provided I think. (hardware specs, OS used, VM/not).
Related
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.
Summary
I currently use the standard method for increasing the screen size width to iPhone 5 (by adding a launch image that is the same size as the iPhone 5 screen).
This launch image is added via the info.PList.
It takes a very very long time for this image to fade into the rootViewController.
Questions
What determines the length of time that the launch screen is displayed for?
Can I control/decrease this timeframe?
Can I control the launch screen time programmatically, despite having not added the launch screen image programmatically?
Many thanks.
That's the time while the OS (iOS in this case) is preparing your application to start.
No. You can not. (You can not do anything but specifying the image file in your configuration).
The launch time is the time when OS is preparing your app. The launch time is the time when OS is preparing your app + the time while ...Launching methods finish calls. And right your code gets an access, it (the launching image) is no more shown. However, obviously, you can just show the same image as your default image in your UI and continue doing some custom preparations. But me personally would consider that like 'wasting a chance to already start "entertaining" of users'.
P.S. This question is actually related to Xamarin pretty not much. Except, that considering Xamarin binaries size can just reduce the app launching time. But generally, many similar questions are widely available through "native iOS"/objective-c questions (even here on stackoverflow).
updated:
Actually, thanks Kirk for the correction on the details about FinishedLaunching. But I would really not recommend to play (freeze) much with that method as if your app won't respond in certain time, it will be terminated. Especially, as the freezing will be 100% just wasting time for users.
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.
I have a C#/.NET 4.0 application that when I start it up shows two windows with about a dozen controls. When I run my program (Debug or Release doesn't matter), before I even do anything in it, I see in Task Manager/Resource Monitor that my program already has upwards of 450MB of private memory. I realize Task Manager isn't the most reliable way of measuring memory usage, but it is one of the most visible to my users.
When I run the VS2010 .NET Memory Allocation performance analysis, for a full run of my program, it reports about 5MB of RAM actually allocated for managed objects (my program normally uses a few unmanaged objects as well, but they are very small and to simplify this investigation I've disabled them, though to no notable effect). Likewise, if I call EmptyWorkingSet() from psapi.dll after my main form has been shown, my private memory drops to ~3.5 MB.
I've already looked at the questions about memory footprints here and here, but those questions seem to be dealing with programs that show up as a couple dozen Megabytes. My program shows almost 500MB, which looks a lot more worrisome.
I can't imagine all of that is from overhead; why is there such a huge discrepancy between the VS profiler and Task Manager?
Update: Interestingly enough, if I comment out a the part of InitializeComponent() that sets up the ImageLists, the number in Task Manager stays under 10MB. I have two sets of PictureBoxes and ImageLists where the PictureBox displays one of four images depending on which radio button in a radio button group is selected.
These lines of code are the ones that seem to trigger the massive memory increase:
//
// directionImageList
//
this.directionImageList.ImageStream = ((System.Windows.Forms.ImageListStreamer)(resources.GetObject("directionImageList.ImageStream")));
this.directionImageList.TransparentColor = System.Drawing.Color.White;
this.directionImageList.Images.SetKeyName(0, "Dir1.png");
this.directionImageList.Images.SetKeyName(1, "Dir2.png");
this.directionImageList.Images.SetKeyName(2, "Dir3.png");
this.directionImageList.Images.SetKeyName(3, "Dir4.png");
//
// modeImageList
//
this.modeImageList.ImageStream = ((System.Windows.Forms.ImageListStreamer)(resources.GetObject("modeImageList.ImageStream")));
this.modeImageList.TransparentColor = System.Drawing.Color.White;
this.modeImageList.Images.SetKeyName(0, "Mode1.png");
this.modeImageList.Images.SetKeyName(1, "Mode2.png");
this.modeImageList.Images.SetKeyName(2, "Mode3.png");
I am using ImageLists so I can use transparency. The Mode images are 100x100 and take up <26KB of disk space each. The Direction images are 208x277 by default and about 75KB on disk. I know png is a compressed format, but even uncompressed in memory I wouldn't expect hundreds of megabytes for these seven pictures.
Is there some inefficiency I'm aware of, and is there an alternate way to dynamically display pictures with transparency?
Conclusion: Something is fishy with the ImageList class. Sometimes it'll lose the alpha channel, and it was causing my program to reserve way more memory than it needed. It also was slowing down the time to draw the main form initially (both while running and in the designer).
Dumping the two ImageLists brought my program down to a much healthier 10MB of RAM. Thanks for all of the suggestions everyone!
My own experience with this problem is that i had 24bit images in my imageList while i had 32bit option set in imagelist's settings.
I've set 24bit in imagelist's properties and the problem has gone. That seems to be a bug which someone should post to MS =)
Sorry for my English.
the .Net framework was designed to run as fast as possible given the resources available. The application will continue to consume more and more memory as it in requested (and is readily available) only letting go when you specifically call the garbage collector or when another application needs the resources it is hogging.
Minimize the app and you should see a better representation of how much memory your application is using.
if you then go back to using it, it will remain at the lower resource state until it gets used and consumes again. minimize it again to see how much is actually (not) being used again. this is built into the .net frameworks memory management system.
Someone explained few reasons where memory jumped from 34 MB to 145 MB: Finding the true memory footprint of a Windows application
png's have transparency already. Just make the white a transparent color and save the image. Then use them normally.
First up, have you tried Debug Diag? It will analyse a dump of your process and give some nifty graphs memory which might help you figure out who has allocated all that memory.
Also, check to make sure that neither your compiled .exe or any of your referneced / loaded assemblies is very large - it is entirely possible that all ~500MB is just loaded dlls. This might happen if (for example) large resources have been embedded into the assembly.
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