I have a WPF application which generates MIDI notes (a sequencer).
Besides the UI thread, there is a timer thread which triggers notes. In general, the timing is ok, but I have the following problem: Whenever I do any navigation, the application seems to "block" (i.e. the timer "stumbles" and the output stops for a short time). This happens when I e.g. open a new window or perform a navigation on a navigation window.
This also happens when I navigate to a page which is already instantiated and has been shown before.
Does anyone have any ideas?
EDIT: I think the actual question is: Does anyone know of a way to make navigation faster?
I'm not sure, but wouldn't your eventhandler (_midiInternalClock_Tick) be executed in your UI thread?
So the MidiInternalClock might be executing in another thread, but the handling of the ticks wouldn't. Like I said, not sure about this.
You might want to separate the code that works with the Midi toolkit to a separate class and then construct the clock en handle it's events in a different thread.
If that doesn't help, I'm at a loss. I guess you would then best ask your question on the CodeProject page.
Related
I have two question regarding WPF Dispatcher Thread.
Does dispatcher thread keeps running when your WPF form is in minimized stat.
I have so many dynamic updated so I flow my updated till winform and then user Timer in winform to update UI. In winform when you minimized winform your Timer will stop working as it is created in UI thread. So my CPU utilization is low. If I have to achieve same behavior in WPF MVVM then how can I achieve that?
Both your questions seem to assume that minimizing your app will somehow stop some of your threads. I don't know where you got that idea, but it's completely wrong. Your UI thread is still running even when you're minimized. How else would it ever process the "restore" command when you un-minimize it? How would Windows be able to get its title to show on the taskbar?
You also seem to think that WPF has a "dispatcher thread" that's somehow special. That's not the case. The Dispatcher takes the place of the Windows message queue, which means it's attached to the UI thread. The thing you call a "dispatcher thread" is the same thing as the UI thread. If you're doing WinForms and WPF in the same app, they both run on the same UI thread (unless you're manually starting new threads and starting your own dispatchers on them, but that's a pretty unusual scenario).
And no, your Timer does not stop running just because your app is minimized (unless you manually wrote code to stop it). Try it: add a call to Console.Beep() in your timer tick event, and then try minimizing your app and see for yourself whether it keeps making noise.
Here's my guess: in your timer's Tick event, your WinForms app calls Invalidate(). When the app is minimized, Invalidate does nothing -- the window isn't shown, so there's nothing to invalidate -- so you see low CPU usage because it's not doing anything.
If you want the same behavior in WPF, your best bet is to add this code to the beginning of your Tick event:
if (WindowState == WindowState.Minimized)
return;
I have an openGL rendering engine coded in unmanaged C++, and I want to embed this in a WPF application. After a little research, I managed to do it by using the handle of a windows forms panel in a windowsformshost, as explained here (2nd solution):
http://www.codeproject.com/Articles/127141/Unmanaged-C-OpenGL-Drawing-and-C-WinForms-WPF-inte/?display=Mobile
So far good. The problem is, I need the render to be real time, and when some UI operation takes too long (like populating a property grid), the render flickers.
Then I guess I need to do the rendering in a separate thread. I tried to use this approach:
http://blogs.msdn.com/b/dwayneneed/archive/2007/04/26/multithreaded-ui-hostvisual.aspx
But it does not work because it seems i cannot place a windowsformshost inside a HostVisual (http://social.msdn.microsoft.com/Forums/en-AU/wpf/thread/124cc95c-a9c6-4aca-a5fc-4f959ea715c3)
So, any idea how can I do this?
If you use double-buffering then it should never flicker. See the section "How to Avoid Flickering?" in the first article you linked to. You can also try inserting Application.DoEvents() calls inside code that takes a long time to execute. Just some suggestions as an alternative to the added complexity of using a threaded solution.
EDIT: just realized WPF does not support DoEvents(), but there are alternatives: http://nmarian.blogspot.com/2007/09/doevents-in-wpf.html
I am attempting to measure the performance for a WPF based application. Currently we have code that times how long it takes to add the content to the WPF render tree. At this point, control is returned to our program. The problem is that there is still a lag before content is displayed on the screen by WPF. For complicated rendering trees, this can be a matter of seconds.
Can you recommend a method to determine when WPF has completed rendering to the screen? I would like these tests to be fully automated and not rely on someone sitting around with a stopwatch.
[update]
Thanks for the suggestions so far.
I have tried waiting for the Loaded and ContentRendered events, but both fire before the content makes it to the screen.
It looks like others are having this issue. I have tried the steps suggested at
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/693fbedb-efa6-413e-ab66-530c6961d3fb/ but still haven't been able force my code to wait for the rendering to complete.
You may use this solution: http://www.japf.fr/2009/10/measure-rendering-time-in-a-wpf-application/
Did you take a look at the WPF Performance suite? You might be able to see the performance and pinpoint problematic code.
You could end the timer after the control's Loaded event since that occurs after the Rendering is complete.
You should use the event ContentRendered of Window.
This will fire every time there's a full rendering sequence, and you can time that.
So I'm planning on writing an application that is largely a windowless application. There will be windows for user interaction, but only at the request of the user. Otherwise the application sits in the system tray and runs a timer, executing some logic every minute or so. My question is this: As far as I can tell, I would put all the related logic in App.xaml.cs (starting the timer, executing the logic at each interval), but for some reason this seems wrong to me.
The app will have a system tray icon that users can interact with to get details, adjust settings, etc., but otherwise the app just sits there and does what it does. Is it appropriate to put all the code in the code-behind for the App.xaml class? I don't know why, but it seems as if I shouldn't, and there should be somewhere else, but I can't really think of anything.
I've never written an app like this before, hence my ignorance. Any advice would be greatly appreciated. Thanks.
James
Even with applications where most interaction is done through windows it's usually a bad idea to put all the code in the code behind. Interactions are often initiated eventhandlers in the code behind but you can put your code in classes you create yourself.
The same goes for applications that do not show a user interface most of the time. Most of the actions will be initiated from the App.xaml.cs but that doesn't mean all the code has to live there. You can encapsulate timers in their own classes that can kick off other code to do work for example. Divide your code up along lines of responsibilities, a window class does UI stuff, domain logic goes into other files etc. That will enable you to create more maintainable applications.
It doesn't sound like the code belongs there, and at most just a call to start the timers.
What does sound like a perfect fit for your issues, is the M-V-VM (Model - View - ViewModel) pattern. As you noteded, it also will 'feel' more correct then attaching logic to your code behind. Using MVVM you can separate your sparse UI into a View, and your code can exist separately in the Model and ViewModel.
I would recomend using the toolkit here, as it also contains good overview documents and a sample you can digest as you create your own solution. Laurent Bugnion has also released a MVVM starter toolkit that you could use to get started.
Also, here is some good stuff to get you started on actually setting up your controls in the system tray.
This is a common problem for all developers, I am looking for the best solution to make windows forms UI responsive.
I have an animated GIF file to show progress of my calcuation on windows form. I took a picture box control and placed animated gif into that. now when my calcuation starts - the animaged gif freezes. I want the reverse, the animation should be visible when i am running the calculation.
Any to the point thoughts? A simple solution is to display a progress bar to the user while doing complex calculations behind the scene
My app is a single threaded application, and I want a simple solution, not looking for multi-threads, or background worker kind of technologies.
Any help?
Multiple threads would be my recommendation. A bit messy first time you try ;)
Simplest model: One thread for the GUI, and one thread for whatever work you need to do.
Check this link.
Application.doevents
You place it in the loop. It gives the UI the time to do its things.
Well, the only real way to do 2 things at once (like do calculations, and still keep responsive) is to use threads. If you won't want to explicitly use threads, then check to see if there are any asynchronous calls you can use to do it in the background. Aside from that, do a lot of Application.DoEvents calls wherever you do lots of work.
I'm going to have to site Jeff on this one:
Coding Horror: Is DoEvents Evil?
"simple solution to display a progress to the user while doing complex calculations behind the scene ?"
"not looking for multi-threads, or background worker kind of technologies."
Which of those wishes is more important to you? You'll have to choose one or the other.