risposta lenta pulsante in WPF App

Question

Per la mia applicazione WPF ho sviluppato una tastiera virtuale. Funziona bene sulla mia macchina di sviluppo. Tuttavia, su macchine lente risposta pulsante di scatto è lento. Dopo che il pulsante viene premuto, v'è un ritardo prima che gli aggiornamenti con il pulsante verso il basso stato e l'evento pulsanti del display. Che cosa posso fare per eliminare questo ritardo? Il problema è un problema di visualizzazione WPF?

pensando che fosse il gestore di eventi che era lento, ho provato diversi approcci per inviare un tasto della tastiera evento premuto. Non importa quello che ho provato, l'interazione è ancora lento. Attualmente sto usando:

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

Importato dal user32.dll. Il mio gestore di eventi è semplificata al punto in cui si sta creando solo i parametri e chiamare la funzione di cui sopra.

Ho anche provato ad utilizzare quanto segue, ma non ha avuto alcun migliore performance:

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

Come posso liberarmi del ritardo?

Answer 1

Si può dire che cosa sta causando il ritardo?

Se c'è qualcosa di lento nel vostro evento Click, si consiglia usare sia ad un Thread separata per eseguire il codice. All'interno del nuovo thread, se si dispone di codice che deve essere eseguito sul thread dell'interfaccia utente, utilizzare Dispatcher.BeginInvoke fare la coda in su da eseguire quando l'utente ha il tempo di elaborazione. Per mantenere l'interfaccia utente sensibile, è necessario tenere alcun codice pesante fuori il thread principale (UI).

Se la tastiera virtuale è locale a un certo Window, a seconda della complessità di quello che stai facendo, si può prendere un approccio che ho usato in passato in cui è sufficiente compilare manualmente in caratteri della tastiera nella TextBox che ha il focus.

Avviso: Ho scritto che il codice oltre 2 anni fa e odio come un risultato. Mentre mi piacerebbe normalmente finta che non esistesse, potrebbe aiutare. Ho fatto meglio da allora, ma il concetto stesso non ha avuto problemi di prestazioni su macchine lente. Mi piacerebbe citare il blog di Jeff Atwood sul codice odi di più è il proprio, ma, beh ...

Modifica Dal momento che hai ancora problemi anche con Click vuoto, si consiglia di guardare in altri potenziali hold-up. È CPU dell'utente maxed al 100% da qualcosa? Entrambi animazioni troppo pesante, o un altro evento potenziale? La maggior parte dei ritardi UI di solito sono il risultato di una CPU sia raggiunto il limite massimo o un evento richiede troppo tempo sul filo della UI.

Una possibilità è se il vostro Window ha AllowsTransparency="True", gran parte del carico di lavoro che normalmente andare alla scheda grafica sarà ora reso nel software, e può avere sanzioni prestazioni pesanti. passato questo, si può dare un'occhiata in questo articolo della Microsoft su Ottimizzazione WPF Application performance per alcuni suggerimenti generali che potrebbe accelerare il processo.

Vorrei suggerire chiunque sviluppi in XAML letto che nell'ultimo articolo. La differenza di prestazioni tra questi piccoli dettagli come l'utilizzo di TextBlock vs Label, o attuare contro DependencyProperty di INotifyPropertyChanged, può davvero aggiungere fino, e il fatto che essi comparativa gli uni contro gli mostra realmente l'importanza di una corretta progettazione.

Answer 2

Proprio imbattuto in questa discussione. Ho un'applicazione WinForms in cui la risposta è stata lenta tasto. Questo è accaduto dopo aver aggiornato a 64 bit di Windows 7. Ho scoperto che se ho cambiato il mio obiettivo progetto "x86" (invece di "Qualsiasi CPU"), la risposta lenta tasto è andato via.

Answer 3

Se il vostro gestore di eventi richiede molto tempo per finire, si blocca l'interfaccia utente per quel tempo. Prova questo gestore di eventi:

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

Il gestore di eventi probabilmente appena finisce più veloce su una macchina più veloce. Per le operazioni lente, si potrebbe desiderare di spingere il lavoro a un altro thread.