QT4 vs QT2: hardware requirements

[Yuri T]

Hello,

Developing a rather simple QT-4-based (tried QT 4.3.3 and 4.6.2) application, which targets to be run on a rather modern processor module, I've discovered that my application processes the setPalette()/show()/hide() methods in QPushButton slots with valueable delays.

I've attached the application code to this message: 4630. In two words:

- the application draws several buttons, which text colors have to be changed if a button pressed. To change the color I connect my object's slots to the QPushButton signals, and change the button's palette with QPushButton::setPalette() in the slot function when a signal (e.g., pressed()) is emitted (when user press the button). And here I observe the delay of ~500 msec before the pressed button changes its text color!

- another thing the application does is displaying the picture (like splash-screen) if the special button pressed, and hiding the picture if the user then clicks on it. The application prepares the appropriate objects (QLabel with setPixmap() and transparent QPushButton) in my class's constructor, and then just show()/hide() the appropriate items. And here I observe the delay of up to 1 second (!) before the picture is shown/hidden after I press the appropriate button.

The h/w board I use has the following features:

- EP9315 CPU (ARM920T core), 200MHz, 16KB caches;
- SDRAM 64MB, 100MHz;
- LCD 800x600, 16bpp;
- touch-screen (tslib-1.0);
- running with Linux kernel 2.6.20.21.

When I run the application described (appropriately modified) on the same h/w board, but with the QT-2.3.10 library - everything works just perfectly, without any perceptible delays!

Though the QT-2.3.10 library I use is patched with the Cirrus Logic patches available here (http://arm.cirrus.com/files/index.php?path=linux%2Freleases%2Flinux-2.6%2F1.0.3%2Flinux-crater_1-0-3%2Fpackages%2Fqt/).

So I do:

to run my QT-2-based application: $ export QWS_DISPLAY=EP93xx:/dev/fb0
to run my QT-4-based application: $ export QWS_DISPLAY=linuxfb:/dev/fb0

I'm not sure that these Cirrus's patches may speed-up things (probably, because I'm not a QT expert ? :) ), but I guess that the 'driver', which is implemented in these patches, just provides a 'link' for QT-2 to the standard linux frame-buffer interface lacked in QT-2 and presented in QT-4.

Am I mistaken here? If not, then what could be the reasons of the described delays in case of using QT-4 instead QT-2? Is there any chance, that the appropriate implementations of QT classes, which I use, require much more CPU computation power in case of QT-4 rather than in case of QT-2? Are there any documents, which describe the "hardware minimals" required for different stable versions of QT or its features?

Thanks in advance for the comments,
Yuri

[wysota]

Qt4 is of course much more complex than Qt2 but simply measuring the delay between pushing the button and seeing the result doesn't say anything about what is causing the delay. It might be either modifying the palette and all things that happen around it or the process of displaying the changes. Maybe you are using some suboptimal display driver? Try running qws with directfb instead of linuxfb and see if it changes anything.

http://doc.trolltech.com/latest/qt-embeddedlinux-directfb.html

[Yuri T]

Hi, Wysota!

Thanks for your point, this definitely makes sense. I'll try my application with directfb (I guess, I should at least rebuild QT with the appropriate support for this; and there is no need in a special kernel driver, since the DirectFb lib is based on the standard linux framebuffer driver for my platform), and then post here the results.

P.S. Any other comments on this topic are welcomed as well : ) actually, there are some improvements supposed to be done to this dummy application, e.g. drawing graphics; so it could be very interesting to know about the h/w requirements for different QT libs to make the optimal choice of the h/w platform for the project.

Regards, Yuri

[wysota]

Actually the only hardware requirement for Qt is that the processor supports some atomic operations. The rest is just a matter of how fast or slow will the applications be.

[Yuri T]

It turns out that the following patch to the original code in the start message of this topic fixes the problem of delays:

--- 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);

Now the QT-4-based application works as quickly as the QT-2-based one: the text color of the buttons pressed are changed without any delays, and there are no delays when I draw my full-screen picture, and redraw the main screen with buttons when the picture is pressed. I guess that the origin of the delays observed with the default Plastique style - is the gradient color of button backgrounds.

[alexpaul]

You use has the following features:

- EP9315 CPU (ARM920T SOM Linux (https://www.graperain.com/ARM-Embedded-System-On-Module/)), 200MHz, 16KB caches;
- SDRAM 64MB, 100MHz;
- LCD 800x600, 16bpp;
- touch-screen (tslib-1.0);
- running with Linux kernel 2.6.20.21.

Qt4 is of course much more complex than Qt2 but simply measuring the delay between pushing the button and seeing the result doesn't say anything about what is causing the delay. It might be either modifying the palette and all things that happen around it or the process of displaying the changes

[d_stranz]

@alexpaul: Please don't go around digging up long-dead posts and replying to them, especially if you aren't really adding anything new.

[anda_skoa]

@alexpaul: Please don't go around digging up long-dead posts and replying to them, especially if you aren't really adding anything new.
In this case clearly spam, the link is not at all to the module the text claims to be.
I moderated the post.

Cheers,
_