Qt best choice for animation on embedded?

Question

I'm looking into technologies for a new embedded product that has a 1 ghz via processor, and a via s3 graphics chip. So far the target platform is Linux, but would like the option to move it over to a windows based platform.

The application would consist of widgets like buttons, graphs, and numeric/text displays. More importantly, the app would contain animating objects, such as fans constantly rotating.

Qt seemed like a good choice because it is cross-platform and has a nice API for a bunch of widgets and an animation framework.

However, this animation framework uses the CPU quite heavily. The target CPU usage for rendering the UI is 40%. Rotating 25 objects with an image uses about 90% CPU.

The thought is to use opengl to animate the objects and take that heavy load off the CPU.

My question is, if Qt the best choice for something like this? Should I be looking more heavily into something like Java 2D?

Answer 1

Qt's primary selling point is that it's a cross-platform GUI toolkit, which is a nice feature but one that Java has already. You may prefer Qt's version, and many people do, but don't use it just because it's cross-platform. This article shows that the Qt animation framework is not yet integrated into Qt.

If you can program in GL then JOGL is an obvious start point, but if you can't be aware that GL programming is not easy. You might also consider Java3D. Possibly what you want can be done in JavaFX.

Answer 2

OpenGL could give you a performance boost:

Qt for Embedded Linux and OpenGL

Or maybe you need a better graphics driver (I don't know if your graphics chip is supported out of the box by Qt Embedded):

Adding an Accelerated Graphics Driver to Qt for Embedded Linux

Answer 3

As far as I recall, Qt's animation framework can be used for continuous animation, but probably isn't the best choice for such. I think it was more designed for transient animations, like sliding a widget around, or growing/shrinking things. I would look into either using OpenGL or possibly QGraphicsView, which allows you to do a more direct sort of drawing.

Additionally, if you look around, you should be able to find instructions for telling Qt to use OpenGL or OpenGL ES as the back-end for the rendering system, which shoud reduce some of the hit to your processor (assuming you haven't already done so).

Answer 4

You need to profile your application to really find out what is wrong there. For example, a fixed shape but continuously rotating graphics item can benefit a lot from item coordinate cache (see QGraphicsItem::setCacheMode). Likewise, fixed images should be cached and kept as long as possible as pixmaps. Color depth may also play an important role. Complex path-based graphics items should be simplified as much as possible.

In short, there are tons of reasons why graphics performance is bad. Without elaborating them and attack them one by one, moving into OpenGL will not really solve the problem. It might accelerate the frame-per-second (due to the obvious advantage of shifting some responsibilities to the graphics hardware), but this is a near-term advantage and quickly diminish in the long-term if the real problem is not uncovered.