2009-12-11 3 views
1

Для моего приложения WPF я разработал виртуальную клавиатуру. Он отлично работает на моей машине разработки. Однако на более медленных машинах реакция нажатия кнопки медленная. После нажатия кнопки задержка перед обновлением дисплея происходит с помощью состояния кнопки и события кнопок. Что я могу сделать, чтобы удалить эту задержку? Проблема связана с проблемой отображения WPF?Замедленный ответ кнопки в приложении WPF

Думаю, что это был обработчик событий, который был медленным, я пробовал несколько подходов к отправке нажатой клавиши клавиатуры. Независимо от того, что я пробовал, взаимодействие все еще медленное. В настоящее время я пользуюсь:

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

Импортирован из user32.dll. Мой обработчик событий упрощен до такой степени, что он только создает параметры для и вызывается вышеупомянутой функции.

Я также попытался использовать следующее, но не имели более высокую производительность:

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

Как я могу избавиться от задержки?

+0

Что делает ваш код в обработчике событий? Можете ли вы воспроизвести проблему, если обработчик не подключен к событию клика? –

ответ

3

Можете ли вы рассказать, что вызывает задержка?

Если в вашем мероприятии Click есть что-то медленное, вы можете использовать отдельный Thread для выполнения кода. Внутри нового потока, если у вас есть код, который должен быть выполнен в потоке пользовательского интерфейса, используйте Dispatcher.BeginInvoke, чтобы поставить его в очередь, чтобы он выполнялся, когда пользовательский интерфейс имеет время обработки. Чтобы поддерживать пользовательский интерфейс, вам нужно сохранить какой-либо тяжелый код с основного (UI) потока.

Если ваша виртуальная клавиатура является локальной определенной Window, в зависимости от сложности того, что вы делаете, вы можете взять an approach I've used in the past где вы просто вручную введите символы с клавиатурой в TextBox, который имеет фокус.

Отказ от ответственности: Я написал этот код более 2 лет назад и ненавижу его в результате. Хотя я обычно притворяюсь, что этого не существует, это может помочь вам. С тех пор я стал лучше, но сама концепция не имела проблем с производительностью на более медленных машинах. Я бы процитировать блог Джеффа Этвуд о коде, который вы больше всего ненавидите ваш собственный, но хорошо ...

Edit: Поскольку вы до сих пор есть проблемы даже с Click пустыми, вы можете посмотреть на другом потенциальный трюме -UPS. Является ли процессор пользователя максимальным, чем 100%? Либо слишком тяжелая анимация, либо другое потенциальное событие? Большинство задержек пользовательского интерфейса обычно являются результатом либо максимизированного центрального процессора, либо события, которое слишком длится в потоке пользовательского интерфейса.

Одной из возможностей является, если ваш Window имеет AllowsTransparency="True", большая часть нагрузки, которая, как правило, идут на видеокарту will now be rendered in software, and can have heavy performance penalties. Past, что вы можете посмотреть на эту статью Microsoft на Optimizing WPF Application Performance некоторые общие советы, которые могут ускорить вашу обработку ,

Я предлагаю, чтобы кто-либо, развивающийся в XAML, прочитал эту последнюю статью.Разница в производительности между такими небольшими деталями, как использование TextBlock против Label, или реализация DependencyProperty по сравнению с INotifyPropertyChanged, действительно может скомпенсироваться, и тот факт, что они проводят сравнительный анализ с каждым, действительно показывает важность правильного дизайна.

+0

Пожалуйста, не говорите людям, чтобы они использовали Dispatcher.BeginInvoke, вот как DoEvents() снова и снова! –

+0

Да, вы правы, это в основном то же самое, и нет смысла звонить BeginInvoke(), когда вы уже находитесь в потоке. Я отредактировал свой ответ, чтобы отразить это. Я не думаю, что это так же плохо, как 'DoEvents()' в том, что вы не заставляете поток пользовательского интерфейса выполнять, вы только ставите в очередь больше кода для выполнения в потоке, чтобы позволить событиям Button возможно стрелять быстрее. Но даже написание этого объяснения звучало плохо. –

+0

, даже с отсутствием в обработчике событий Click, реакция все еще медленная. –

1

Если ваш обработчик событий занимает много времени, он закроет интерфейс для этого времени. Попробуйте этот обработчик события :

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

Ваш обработчик события, вероятно, просто заканчивается быстрее на более быстрой машине. Для медленных операций вам может потребоваться переместить работу в другой поток.

+0

Я извлек весь код из своего обработчика событий. Он будет называться, но ничего не сделает. Ответ кнопки все еще очень задерживается. После нажатия кнопки появляется хорошее 3/4 секунды до того, как экран обновится кнопкой в ​​состоянии «вниз». –

2

Просто пробежал эту дискуссию. У меня есть приложение WinForms, в котором реакция кнопки была медленной. Это произошло после того, как я обновился до 64-разрядной Windows 7. Я обнаружил, что если бы я изменил цель проекта на «x86» (вместо «Any CPU»), медленный ответ кнопки исчез.

+0

Волшебно, это действительно решило мою проблему с WPF тоже. – phantasm