Important: Please read the Qt Code of Conduct -

Drawing graphs in Qt embedded - advices

  • Hi all,

    this is my first post to the forum so, first of all, "hello!" to everyone. Secondly, I would apologize for my English. I'll try to be as clearer as possible.

    I'm currently working on an embedded project (a linux device with a 500MHz Imx-28 arm processor and 64Mb ram). The project consists in drawing a series of graph in real-time (as data comes from a radio devide of the board). I've provided different implementations which improved performance but none of them seems to guarantee the required responsiveness. Since my knowledge of the framework is quite limited I think that having some kind of feedback can help me out in choosing the next step.

    The current implementation is composed as follows: a QGraphicsView contains a QGraphicsScene. The QGraphicsView uses fitInView to squeeze 5x screen width of number of values. The QGraphicsScene contains six QGraphicsPathItem (the six graphs) instances and the corresponding QPainterPath objects. In the constructor of the scene we have:

    @pathL1 = QPainterPath(QPointF(0,60));
    pathL2 = QPainterPath(QPointF(0,170));
    pathL3 = QPainterPath(QPointF(0,280));
    pathAVR = QPainterPath(QPointF(0,390));
    pathAVL = QPainterPath(QPointF(0,500));
    pathAVF = QPainterPath(QPointF(0,610));

    pathItemL1 = this->addPath(pathL1);
    pathItemL2 = this->addPath(pathL2);
    pathItemL3 = this->addPath(pathL3);
    pathItemAVR = this->addPath(pathAVR);
    pathItemAVL = this->addPath(pathAVL);
    pathItemAVF = this->addPath(pathAVF);

    Note that I'm talking about the constructor of QGraphicsScene since, at the beginning, I've extended this class to reimplement drawbackground and paint a the background is a single QPixMap, set via stylesheets. Is this better? Should I use a QImage?

    Once a signal with data arrives to the scene the slot which updates the paths is called and a code like the following is executed for each path:

    pathL1.lineTo(pathL1.currentPosition().x() +1.5, 60 - l1);

    In other words the QPaintPath is updated with a new position and is set again into the corresponding QGraphicsPathItem. No specific management of the paiting events is provided (I just leave them to the QT graphics system). This approach works quite well for what concerns the painting itself. It paints fast, even if after sometimes there's a degradation of performance. Such degradation must surely be investigated (is it the approach itself of the queueing of information from the thread that fetches data to the GUI thread? I must profile.)

    The point is that, when the sceen is full of items (at maximum 15000 points can be shown at a time) scrolling become difficult. Supposing my approach is correct, are there other ways to improve the performance in scrolling the QGraphicsView? Even by applying the caching, mimumum viewport update and rendering hints, it is still two laggy.

    Since I do not have to apply specific operation provided by QGraphicsView/Scene, would it be better to draw on an image (QImage / QPixmap) which represents the background of my graph? Does it make sense as a way to improve performances? I was thinking about a QScrollArea containing the image.

    Thanks in advance.

  • Hi! There is a library based on Qt called "Qwt": providing widgets for drawing 2D plot & graphs. You might wanna have a look at it if you haven't already. But I can say nothing about its perfomance since I havent tried it myself.

  • Hi Terenty! Qwt has been my first choice since the beginning of this project. Unfortunately the cross-compiling toolchain I use had problems in handling Qwt. Well, I'm going to investigate more in-depth the possibility to use this library. Thanks for the time spent in answering my question! :)

  • You may also want to take a look at "QCustomPlot": . I never tried it myself but I think it is easier to use than Qwt. I used Qwt on my project year ago but I am always having problem adding it to my mainwindow.

  • Thanks to point me to QCustomPlot Code_ReaQtor. It seems very interesting. :)

    In the meanwhile, I've tried to recompile qwt for my embedded system but still had trouble. However, it seems that the problem is only related to a linking issue with the qwt and the cross-compiling toolchain used is not directly involved. I'll investigate the issue further these days.

    As a next step, I'm going to give QCustomPlot a try. Thanks again.

Log in to reply