views:

279

answers:

2

For my WPF application I have developed a virtual keyboard. It runs fine on my development machine. However, on slower machines the button click response is slow. After the button is clicked, there is a delay before the display updates with the button down state and the buttons event. What can I do to remove this delay? Is the problem a WPF display issue?

Thinking it was the event handler that was slow, I've tried several approaches to send a keyboard key pressed event. No matter what I've tried, the interaction is still slow. Currently I am using:

SendInput(uint nInputs, ref INPUT pInputs, int cbSize);

Imported from user32.dll. My event handler is simplified to the point where it is only creating the parameters for and calling the above function.

I've also tried using the following, but didn't have any better performance:

 System.Windows.Input.Keyboard.FocusedElement.RaiseEvent(...)

How can I get rid of the delay?

+1  A: 

If your event handler takes a long time to finish, it will lock up the UI for that time. Try this event handler:

  private void button1_Click(object sender, RoutedEventArgs e)
  {
     System.Threading.Thread.Sleep(5000);
  }

Your event handler probably just finishes quicker on a faster machine. For slow operations, you might want to push the work to another thread.

Robert Jeppesen
I've taken all code out of my event handler. It will be called but will do nothing. The button response is still very delayed. After a button is clicked there is a good 3/4 of a second before the screen updates with the button in a down state.
Dan Vogel
+2  A: 

Can you tell what is causing your delay?

If there is something slow in your Click event, you may want to either use a seperate Thread to execute the code. Within the new thread, if you have code that must be executed on the UI Thread, use Dispatcher.BeginInvoke to queue it up to be executed when the UI has processing time. To keep the UI responsive, you need to keep any heavy code off the main (UI) thread.

If your virtual keyboard is local to a certain Window, depending on the complexity of what you're doing, you can take an approach I've used in the past where you just manually fill in keyboard characters into the TextBox that has focus.

Disclaimer: I wrote that code over 2 years ago and hate it as a result. While I'd normally pretend it didn't exist, it may help you out. I've made it better since then, but the concept itself had no performance issues on slower machines. I'd quote Jeff Atwood's blog about the code you hate most is your own, but, well...

Edit: Since you still have issues even with Click empty, you may want to look at other potential hold-ups. Is the user's CPU maxed out at 100% from something? Either too heavy animations, or another potential event? Most UI delays are usually a result of either a maxed out CPU or an event taking too long on the UI's thread.

One possibility is if your Window has AllowsTransparency="True", much of the workload that would normally go to the graphics card will now be rendered in software, and can have heavy performance penalties. Past that, you can take a look at this Microsoft article on Optimizing WPF Application Performance for some general tips which could speed up your processing.

I would suggest anyone developing in XAML read that last article. The difference in performance between such little details such as using TextBlock vs. Label, or implementing DependencyProperty's vs. INotifyPropertyChanged, can really add up, and the fact that they do benchmarking against each really shows the importance of proper design.

Will Eddins
Please don't tell people to use Dispatcher.BeginInvoke, thats like DoEvents() all over again!
Robert Jeppesen
Yeah, you're right, it's basically the same and there's really no point in calling BeginInvoke() when you're already on the thread. I've edited my answer to reflect that. I don't think it's as bad as `DoEvents()` in that you're not forcing the UI thread to execute, you'd only be queuing up more code to execute on the thread in order to allow your Button events to possibly fire faster. But even typing out that explanation sounded bad.
Will Eddins
even with nothing in the Click event handler, the response is still slow.
Dan Vogel
I've added to my answer with some more suggestions. The Optimizing WPF Application Performance alone would be a good read, just to make sure you're designing your XAML and classes in ways that won't impact performance.
Will Eddins