Здравствуйте,

 Столкнулся с проблемой "заторможенности" довольно простого QT приложения на не самом отсталом процессорном модуле при использовании последних версий библиотек QT (пробовал 4.3.3 и 4.6.2).

 QT приложение, о котором идёт речь (см. код в app.qt4.tar.bz2 в атачменте):

1) рисует четыре кнопки pushButton_1/2/3/4 с надписями; при нажатии на кнопку должно изменять цвет надписи на ней и восстанавливать цвет надписи кнопки, которая была нажата до данной (типа подсвечивается последняя нажатая кнопка). Для манипуляций с цветом подключаю слоты создаваемого приложением наследника QObject к сигналам кнопок (например, pressed()) и в слотах использую QPushButton::setPalette().

2) кроме того в приложении есть пятая кнопка, idleButton, при нажатии на которую во весь экран должна рисоваться картинка (типа заставка), которая должна пропадать при нажатии на неё. QSplashScreen не использую (т.к. поверх картинки должна быть часто меняющаяся надпись [текущее время] - и постоянные QSplashScreen::message() совсем уж сильно загружают процессор - т.к. они, как я понимаю, приводят к перерисовке всей картинки), а рисую картинку в QLabel с помощью setPixmap() и рисую поверх прозрачную кнопку, picButton, на весь экран, сигнал с которой подключен к слоту делающему hide() для QLabel и этой большой кнопки.

 Процессорный модуль, на котором это запускается, TionPro v2. rev3 ([1]: http://www.zao-zeo.ru/catalog/sbc/79-tion-pro2):

- построен на базе контроллера EP9315 (с ядром ARM920T), работающего на 200 MHz и имеющего кэши по 16 KB;
- SDRAM 64MB на 100 MHz;
- всё это под управлением Linux 2.6.20.21. Графика: LCD 800x600, 16bpp (/dev/fb0); ввод: touch screen (/dev/misc/ep93xx_ts и tslib-1.0).

 Проблема заключается:

 в случае (1): в визуально заметной (и от того довольно неприятной) задержке при изменении цвета надписи нажимаемой кнопки pushButton_i [задержка где-то в несколько сотен миллисекунд],

 в случае (2): в задержке прежде чем начинает рисоваться картинка после нажатия на кнопку idleButton, а также прежде чем картинка спрячется после нажатия на picButton [задержки до секунды с небольшим!].

 При этом, если соответствующим образом адаптированное приложение я запускаю с QT-2.3.10 - всё работает просто идеально, без каких бы то ни было визуально заметных задержек!

 Единственно, что QT-2.3.10 я собираю с наложением некоторых патчей ([2]: http://arm.cirrus.com/files/index.php?path=linux%2Freleases%2Flinux-2.6%2F1.0.3%2Flinux-crater_1-0-3%2Fpackages%2Fqt/) от производителя EP93xx, Cirrus. В результате:
- при использовании QT-2 экспортирую QWS_DISPLAY=EP93xx:/dev/fb0;
- при использовании QT-4 экспортирую QWS_DISPLAY=linuxfb:/dev/fb0.

 Собственно вопросы:

1) имелся ли у кого-нибудь успешный опыт по использованию QT-4-based приложений на железе с аналогичными (или хуже) характеристиками? Если да - то что я в своём приложении (см. код в атачменте) делаю криминального?

2) есть ли смысл ожидать исчезновения обозначенных проблем в случае использования аналогичной доски (например, TionPro270, [3]: http://www.zao-zeo.ru/catalog/sbc/67-tion-pro270), но выполненной на базе контроллера PXA270, у которого частота CPU 400MHz+ против 200MHz EP9315, да и кэш вдвое больше; кроме того, может frame-buffer драйвер какой-то более продвинутый (pxa270 linux порт вроде бы в mainstream, в отличии от ep9315 порта, сделанного Cirrus Logic, [4]: http://arm.cirrus.com/files/index.php?path=linux%2Freleases%2Flinux-2.6%2F1.0.3%2Flinux-crater_1-0-3%2Fpackages%2Fkernel%2Flinux/).

3) что есть всё же наиболее вероятная причина такого существенного отличия "откликаемости" приложения при использовании QT-4 и QT-2? Повышенные требования QT-4 к аппаратуре или специализированный дисплейный драйвер библиотеки QT-2 ([2]: http://arm.cirrus.com/files/index.php?path=linux%2Freleases%2Flinux-2.6%2F1.0.3%2Flinux-crater_1-0-3%2Fpackages%2Fqt/)?

4) не нашёл на Trolltech, но может кто-то располагает информацией (если такая существует) по hardware minimum, который должен быть для использования той или иной версии QT (или тех или иных её фич)?

 Заранее спасибо за комментарии.

---

[1] Характеристики TionPro-v2
 http://www.zao-zeo.ru/catalog/sbc/79-tion-pro2

[2] патчи от Cirrus Logic для использования QT-2.3.10 с EP93xx:
 http://arm.cirrus.com/files/index.php?path=linux%2Freleases%2Flinux-2.6%2F1.0.3%2Flinux-crater_1-0-3%2Fpackages%2Fqt/

[3] Характеристики TionPro-270
 http://www.zao-zeo.ru/catalog/sbc/67-tion-pro270

[4] патчи от Cirrus Logic с портом Linux-2.6.20.4 для EP93xx (к сожалению, отдельного патча с frame-buffer драйвером они не выложили, всё в одном, если нужно и как-то поможет прояснить ситуацию - могу выслать код фрейм-буфер драйвера для этого процессора отдельно):
 http://arm.cirrus.com/files/index.php?path=linux%2Freleases%2Flinux-2.6%2F1.0.3%2Flinux-crater_1-0-3%2Fpackages%2Fkernel%2Flinux/

я думаю тебе сюда http://doc.trolltech.com/qtextended4.4/qt-embedded-accel.html... я сильно не вникал в патчи .... но по моему часть них нацелены именно на это...

Под профайлером я имел ввиду gprof.
Насчет PXA270: я использовал ванильное ядро 2.6.29-1, там нет никакого ускорения, просто производительности хватает для программного blit'а.

спасибо всем за комментарии. как выяснилось, ларчик открывался довольно просто. следующее изменение в код, что в атачменте стартового сообщения этого топика - сводит к минимуму наблюдаемые задержки - работает по ощущениям не медленнее чем с QT-2:

--- a/main.cpp  2010-05-18 00:16:58.341568500 +0400
+++ b/main.cpp  2010-05-18 00:16:27.147619000 +0400
@@ -1,4 +1,5 @@
 #include <QApplication>
+#include <QStyleFactory>
 
 #include "ui_but.h"
 #include "main.h"
@@ -115,6 +116,8 @@ MyWidget::MyWidget(QMainWindow *w)
  */
 int main(void)
 {
+       QApplication::setStyle(QStyleFactory::create("Windows"));
+
        char *argv[] = {"but.qt4", "-qws"};
        int argc = sizeof(argv)/sizeof(argv[0]);
        QApplication app(argc, argv);

 Насколько я понимаю, Windows стиль отличается от дефолтного Plastique - отсутствием градиентов кнопок. Я почему-то предполагал, что градиенты вычисляются только раз, при создании объекта, и не должны влиять на производительность - но эксперимент показывает, что это не так: с указанным фиксом теперь без задержек отображаются как изменения цвета текста кнопки при нажатии на неё, так и отрисовка полноэкранной картинки, и отрисовка основного экрана с кнопками после нажатия на картинку.