I really need to calculate responsiveness of my UI. Some suggested to use WpfPerf.exe (performance profiling tools for WPF). It works great however it does not have logging so it shows only last 1 minute of FPS as image.
However i need statistical information. The gui runs laggy so i need to record when exactly gui is refreshed. When there is no lag it should be refreshed each 0.5 seconds.
So i wonder anyhow i can record the time whenever gui is refreshed ?
.net 4.5.2 c# wpf
To record the time the GUI is refreshed. You may refer to
Why is Frame Rate in WPF Irregular and Not Limited To Monitor Refresh?
It may be out of topic. I would like to share what I do to improve my application last week.
Use visual studio performance and diagnostic, if available, to find bottleneck.
use BackgroundWorker to prepare data, instead of doing it in UI thread.
use data virtulization for dispalying huge amount data, for example million rows. This article provides an excellent solution for displaying millon rows data smoothly.
Hope It will help.
Related
I am developing a WPF application and currently writing an article about it. I am at the experiments phase. I need to write responsiveness of GUI. However is that statistically possible to count how many times GUI is refreshed in certain time? When there is no lag full responsive i am updating with 0.5 second interval however there is being lag and it get updated with a delay. It is like half time frozen.
Can i measure this somehow ?
c# .net 4.5.2 WPF application
You can use WPF Performance Suite to get framerate and various other stats regarding gui. Check the Perforator section on details about gui stats.
I want to develop an app which downloads small files continuously when my app is not in the foreground and sends a notification if certain conditions are met.
Problem is that periodic agents have a scheduled interval of 30 minutes and a duration of 10 seconds, while resource-intensive agents have a duration of 10 minutes and need an external power source.
How could I do to achieve my goal ?
If you don't mind upgrading your Application to WP8.1 then you can use a very simple class to download a file in the background.
BackgroundDownloader class. There is really good example at the bottom of the page as well.
Useful Links if you want to understand more:
Transferring data in the background Describes the events of the BackgroundDownloader.
Periodic Tasks should really only do something very simple IMHO (that is why they have those restriction, not download something continuously) for example, Grab the latest news from a feed and update the Secondary Title.
I have the following scenario in mind:
I want to send (via serial port) some commands to a device. This device does send me back a continuous stream of data (max. 12000 values per second).
To control some settings I need some buttons to send commands to the device to start/stop/change settings before and during data stream. Also I want to have a real time plot of this data. I will filter this data of course. Also at certain timestamps there will be a signal which indicates that I want to cut out a certain window of the received data.
This means I will have two charts. I made already some progress using WPF but now when I interact (zoom/pan) with the lower chart, the upper one freezes noticeable. This is because both have do be refreshed very often!
Work (data receiving/filtering) is done using threads but the update of the plot has to be done within the ui thread.
Any ideas how to solve this issue? Maybe using multiple processes?
You should use Reactive Extensions. It was built for this kind of thing.
http://msdn.microsoft.com/en-us/data/gg577609.aspx
Requesting a clear, picturesque explanation of Reactive Extensions (RX)?
On this second link, although the topic is javascript, much of what it says is about Reactive Extensions and cross-applies to Rx in C#.
I'm making a similar WPF application with real-time waveforms (about 500Hz). I have a background threads that receives real-time data, a separate threads to process them and prepare the data for drawing (I have a buffer with the "size" of the screen where I put the prepared values). In the UI thread I draw the waveforms to the RenderTargetBitmap which is in the end is rendered to the Canvas. This technique allows me have a lot of real-time waveforms on the screen and have zoom and pan working without any problems (about 40-50 fps).
Please let me know if you need some technical details, I can later share them with you.
I think you have some code in the UI thread that is not optimized well or can be moved to the background thread.
Btw, do you use any framework for charts?
Edit
philologon is right, you should use Rx for real-time data, it simplifies code A LOT. I also use them in my project.
Its a commercial product but there is a real-time WPF chart which can handle this use-case and then some. Please take a look at the Tutorial below:
http://www.scichart.com/synchronizing-chartmodifier-mouse-events-across-charts/
There is a live Silverlight demo of this behaviour here:
Sync Multichart Mouse Silverlight Demo
And this chart should be able to handle zooming while inputting values at high speed:
Realtime Performance Demo
Disclosure: I am the owner and tech-lead of SciChart
I'm having a problem with timing in XNA 4.0, writing in C# and using Visual Studio 2010 express.
I'm not writing a game exactly, but I'm trying to use XNA for it's simplified content pipeline, drawing, and timing. What I'm trying to do is write a program that can time a user's response to onscreen stimuli at very fine resolutions - less than 5 ms, ideally.
To do this, I need to call the update routine (so I can poll the keyboard) no less than once every 5 ms. Even in variable step timing, I can't get the timing below about 16 ms per call. This doesn't appear to have anything to do with the amount of processing that I do in my update and draw routines. I can comment out everything in both routines and the program still spends roughly 16.66 ms on each iteration.
In fixed step timing, I can set the target to about 60 iterations per second (16.66 ms between updates), but if I try to go any faster than that, the IsRunningSlowly flag is tripped, and the game seems to try to compensate - several iterations will run faster than 60 iterations per second, and then 1 iteration will run slower.
So I guess my question is this: is the 60 iterations per second the upper limit for XNA? Is it possible to circumvent it? Should I just ditch XNA altogether?
I really appreciate your time and knowledge. Thanks in advance.
The problem you are having is due to VSync. Disable it in XNA by adding this line to your game's constructor (assuming you have the default GraphicsDeviceManager graphics):
graphics.SynchronizeWithVerticalRetrace = false;
This will allow your game to run "fast as possible". This should be "good enough" for your purposes.
See this blog post for a description of timing in XNA.
If you wanted to get more fancy: For XNA on Windows I would consider using the Windows event loop and a high resolution timer directly. Note that Game in XNA (on Windows and Xbox 360) is entirely optional.
You'd want to move as many slow operations (eg: update and draw) and blocking operations (eg: vsync) off the main thread. Note that input in XNA can only be handled on the main thread. I think you can create the graphics device on a separate thread - although I have never tried it.
You should note that, if you are measuring reaction times, there is lag in between sending a "present" command to the GPU, and that content actually appearing on screen.
I'm not expert to XNA development, but, I know I have already similar "problem" in windows phone. (slowly problem).
When you have a lot of treatment, use multithreading programming,,
msdn : "Applications that use multithreading are more responsive to user input because the user interface stays active as processor-intensive tasks execute on separate threads. Multithreading is also useful when you create scalable applications, because you can add threads as the workload increases. "
Hope I help you...
As you might surmise from the question title, we are required to decode and display multiple (e.g., eight) H.264 encoded videos at the same time (and keep them all time synchronized, but that's another question for another time). The videos are usually at at 25 FPS with a resolution of 640x480.
I'm going to provide a bit of background before I get to the crux of the problem.
The feature needs to be baked into a fairly large C# 3.5 (WinForms) application. The videos will occupy rectangles in the application - the managed code needs to be able to specify where each video is drawn as well as it's size.
We get the H264 packets in C# and fire them into a native H264 decoder to get YUV12 image data.
An early attempt consisted of converting the YUV12 images to RGB24 and BitBlt'ing them to a HWND passed into the native code from C#. While functional, all BitBlt'ing had to happen on the UI thread which caused it to bog down when displaying more than a couple videos (on a 2.6 GHZ core 2 duo).
The current attempt spins up one-thread-per-cpu-core on startup and load balances the decoding/displaying of videos across these threads. The performance of this is mind-blasting (I find watching task manager much more interesting than the videos being displayed). UI-wise, it leaves a lot to be desired.
The millisecond we started drawing to an HWND created on the UI thread (e.g., a panel docked in a WinForms control) from a non-UI thread, we started getting all sorts of funky behavior due to the un-thread-safeness of WinForms. This led us to create the HWND's in native code and draw to those, with C# providing the rectangles they should be drawn to in screen coordinates.
Gah! CanOfWorms.Open().
Problem: When the C# application receives focus, it jumps to the front of the Z-Order and hides the video windows.
Solution: Place the video windows Always On Top.
Problem: When the user switches to another application, the video windows are still on top.
Solution: Detect activation and deactivation of the C# application and show/hide the video windows accordingly.
Problem: User says, "I want my videos playing on one monitor while I edit a Word document in the other!"
Solution: Tell user to shut up and that Word sucks anyways.
Problem: I get fired.
etc. etc.
I guess the crux of the problem is that we have HWND's created on a non-UI thread and we want to 'simulate' those being embedded in the C# application.
Any thoughts/suggestions? Am I completely out to lunch here?
I'm more than open to taking a completely different approach if one exists (This project required a lot of learning - winning the lottery would have a greater likelihood than me having picked the best approach at every step along the road).
Forget about BitBlt-ing and do this:
for each window you want your video to be played, create one DirectShow graph and attach the renderer of the graph to that window
before renderer in the graph put the samplegrabber filter. It will allow you to have callback in which you'll be able to fill the buffer
instead of blitting, decode to the buffer provided in samplegrabber.
In addition, I guess that you'll be able to put raw YUV12 into the buffer, as VMRenderer is able to display them directly.
Use DirectShowNet library.
EDIT:
And yes, BTW, if the videos are on the same 'canvas', you can use same technique with renderer and create only one large window, then shift decoded video rectangles 'by hand' and put them into the framebuffers buffer.
YET ANOTHER EDIT:
BitBlts are ALWAYS serialized, i.e. they can't run in parallel.
The millisecond we started drawing to an HWND created on the UI thread (e.g., a panel docked in a WinForms control) from a non-UI thread, we started getting all sorts of funky behavior due to the un-thread-safeness of WinForms. This led us to create the HWND's in native code and draw to those, with C# providing the rectangles they should be drawn to in screen coordinates.
What kind of funky behavior?
If you mean flickering or drawing delay, have you tried to lock() the panel or any other class for thread/drawing synchronisation?
Again: Whats the exact problem when you send the data to the decoder, receive a image, convert it and then draw it with an OnPaint handler. (Setup a different thread that loops at 25fps, call panel1.Invalidate() then)
I guess the crux of the problem is that we have HWND's created on a non-UI thread and we want to 'simulate' those being embedded in the C# application.
Don't do that. Try to draw the received data in your c# application.
In general, I wouldn't reccomend mixing native code and c#. Having the h264 decoder in native code is the only exception here.
Use your threads to decode the video packets (as you already do) then have one thread that loops and calls Invalidate(as said above). Then have an OnPaint handler for each panel you are displaying a video in. In this handler get the most recent video picture and draw it (e.Graphics).
I hope this helps, but also need more information about the problem...
I like the DirectShow answer posted earlier, but I wanted to include an additional option that might be easier for you to implement, based on this excerpt from your question:
While functional, all BitBlt'ing had to happen on the UI thread which caused it to bog down when displaying more than a couple videos
My idea is to start from that code, and use the Async CTP for Visual Studio 2010 that is currently available and includes a go-live license. From there it should be a relatively simple to modify this existing code to be more responsive: just add await and async keywords in a few places and the rest of the code should be largely unchanged.