4

We are trying to use Qt 4.8.5 for some Linux-based embedded devices in our company. I use Qt embedded without X server. I need to plot measured data and update them very often (20-30fps, but only a small portion of the widget). The system is ARM based, 400Mhz, have no GPU and no FPU. I subclassed QWidget and overridden the paintEvent(). I have WA_OpaquePaintEvent and WA_StaticContents set. For testing, my paint event is empty, and I call the update() function of the widget form a timer set to 50ms. My problem is that the empty update is eating up 30% of the CPU. The amount varies with the area of the update, so I think QT may redraw something in the background. I have read many posts but I cannot find the solution for my problem. If I comment out the update call, the CPU usage drops to ~1% (even if I generate a sine in the timer for testing the widget, which should be much more complex than an empty function call). My widget is rectangular, is not transparent and I want to handle the full drawing procedure from the paint event.

Is it possible to reduce this overhead, and handle the whole painting process by my own?

xdever
  • 41
  • 4
  • If you want to update only a small part, did you try with restricting the updated area via update(QRect) or update(QRegion)? – Frank Osterfeld Aug 04 '13 at 16:41
  • Yes, I tried. If I do so, the CPU usage drops in respection of the area size. But for example it is cheaper to update a 25 pixel wide region than the two 5 pixel regions separated by 15 unchanged pixels, which is not updated. For debugging, I entriely disabled my painter, and the paintEvent is only an empty function. My problem is that if I don't do anything in the paintEvent function, why it uses CPU at all? (I know it must be scheduled and called, but it should be a minimal overhead, and shoud not be proportional to updated area). – xdever Aug 04 '13 at 17:10
  • Well, the widget will also be updated if you paint nothing explicitly, as any previous content will be cleared. – Frank Osterfeld Aug 04 '13 at 17:18
  • Can this be somehow turned off? If I draw the content it will be cleared anyway so it is yust wasting of expensive CPU cycles. And it loads the CPU even if I draw the widget (the 2x5 vs 1x25 pixel update from my previous comment). – xdever Aug 04 '13 at 20:09
  • Another: If the clearing eats up the cpu cycles, then why is clearing a two separate 5x600 pixel columns are slower than clearing a single 25x600? – xdever Aug 04 '13 at 20:12
  • @xdever, I suggest you share some code with us; it may be that the problem you're seeing is not actually due to what you've described to us. – TheDarkKnight Aug 05 '13 at 07:38
  • remember that empty while loop will also eat your CPU. – Kamil Klimek Aug 05 '13 at 13:24
  • Did you tried Qt::WA_NoSystemBackground ? – Sylvain V Aug 06 '13 at 14:43
  • Have you tried setting [Qt::WA_PaintOnScreen](http://harmattan-dev.nokia.com/docs/library/html/qt4/qt.html#WidgetAttribute-enum)? Your success with this depends on the screen driver you are using. It disables the double buffering which may be causing the CPU overhead you are seeing. – dunc123 Aug 06 '13 at 15:15

1 Answers1

1

The "empty update" is not empty - it repaints the whole window :)

Have you read the below?

To rapidly update custom widgets with simple background colors, such as real-time plotting or graphing widgets, it is better to define a suitable background color (using setBackgroundRole() with the QPalette::Window role), set the autoFillBackground property, and only implement the necessary drawing functionality in the widget's paintEvent().

You should also be using QWidget::scroll(), since internally it does scroll the backing store of the window, and that's much more efficient than repainting the entire thing if only a tiny slice is added to it.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313