Производительность GDI на мобильном устройстве Windows или CE - PullRequest
2 голосов
/ 04 марта 2009

У меня есть приложение Windows CE, которое использует много векторной графики и местами довольно медленно. В настоящее время я использую GDI для рендеринга с помощью растрового изображения для обновления без мерцания. Как правило, я смотрю на часть большой 3d-карты. На некоторых устройствах (например, 166 МГц SH4) это становится медленным с 3-5-секундным временем обновления для больших наборов данных. У меня вопрос такой:

  • Кто-нибудь делал какие-либо сравнения относительной скорости графических операций на Windows Mobile по сравнению с Win32. Другими словами, профилирование результатов из версии программного обеспечения для Win32, применимой к версии WinCE, при условии, что мы ищем только вызовы GDI.

  • Кто-нибудь пробовал профилирование на платформе WinCE (приложение C ++), если да, с помощью каких инструментов.

  • Кто-нибудь знает какие-либо методы для повышения скорости рисования в Windows CE. В настоящее время я смотрю на FastGraph после отзыва на предыдущий вопрос , но это более долгосрочное решение. Плохо, и все как есть, я ищу что-то более быстрое для реализации в следующем выпуске.

Ответы [ 3 ]

5 голосов
/ 14 августа 2011

До Windows CE 6.0 - следовательно, включая все версии Windows Mobile / Windows Embedded Handheld - графический код был реализован в другом процессе (GWES.EXE), требуя межпроцессного вызова каждый раз, когда вы выполняете вызов GDI. Межпроцессные вызовы CE 5.x намного дешевле, чем на рабочем столе, но все же дороже, чем простой вызов функции или вызов в режиме ядра.

На рабочем столе GDI реализован в режиме ядра начиная с NT 4.0. В оригинальной NT 3.1 это было похоже на модель CE, межпроцессные вызовы. Чтобы уменьшить накладные расходы на межпроцессные вызовы или переключатели режима пользователь / ядро, рабочий стол GDI объединяет операции на стороне пользовательского режима до тех пор, пока вы не сделаете что-то, требующее очистки очереди - например, выбрав другое перо или кисть или используя один устаревших функций, которые возвращают что-то отличное от BOOL - или буфер заполнен, или вы явно очищаете его, вызывая GdiFlush.

В Windows CE такой пакетной функции нет - все вызовы приводят к прямому вызову процесса GWES, что делает его намного медленнее. Вы можете уменьшить его, выполняя как можно больше работы в каждом вызове. Если вам нужна сложная линия, рассмотрите Polyline, а не отдельные вызовы MoveToEx / LineTo. Старайтесь касаться каждого пикселя только один раз, а не визуализировать перекрывающиеся объекты, и использовать недопустимую область, чтобы рисовать только те части экрана, которые требуют перекраски (используйте GetUpdateRgn или GetUpdateRect, но делайте это перед вызовом BeginPaint, что означает регион действителен).

Модель графического ускорения CE довольно проста и основана на бит-битах. Он не поддерживает расширенный набор возможностей, поддерживаемых драйверами настольных устройств модели Windows 2000. Доступно ли какое-либо ускорение, зависит от того, есть ли на оборудовании даже чип-ускоритель - многие устройства будут использовать контроллер ЖК-дисплея, встроенный в процессор приложения, который обычно не ускоряется.

Вы можете смоделировать поведение CE на рабочем столе, отключив пакетирование, используя GdiSetBatchLimit, чтобы установить ограничение на 1. Также рассмотрите возможность использования графического драйвера SVGA для отключения ускорения. В Windows Vista или Windows 7 GDI не ускоряется, если вы используете среду Aero, все операции реализованы в программном обеспечении, хотя в Windows 7 добавлены некоторые новые возможности аппаратного ускорения.

Windows CE 6.0 имеет новое ядро ​​и модель процесса, которая переводит GDI в режим ядра, как в настольной Windows (до Vista), поэтому стоимость вызова функции GDI должна быть немного снижена. Там еще нет дозирования.

2 голосов
/ 10 марта 2009

Я не очень хорошо разбираюсь в графической стороне вещей, но по своему опыту, если вы хотите быть быстрым в некоторых конкретных вещах, связанных с аппаратным обеспечением, чем ближе к «металлу», тем быстрее вы можете получить (и тем сложнее это становится!). Таким образом, вы можете использовать Direct Draw или Direct 3D (хотя я думаю, что они отказываются от D3D и переходят на OpenGL ES для WM7). Вы можете посмотреть, как разработчики игр используют.

По вопросу о профилях я не нашел ни одного, но строю свой собственный .

1 голос
/ 04 марта 2009

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

Извините, у меня нет ответов на два последних вопроса.

...