Qwt 6.3.0 (from qwt-code-r2921-trunk) compilation fails on Ubuntu 18.04.

Hi.

I need to port the Qwt build system from the qmake to QBS in my project. Previous Qwt stable version 6.2.0 was compiled successfully on any Linux. But now I have updated it to the version from the trunk r2921.

And right now compilation fails with following errors:

Quote:

---

/usr/bin/g++ -g -O0 -Wall -Wextra -m64 -pipe -fexceptions -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -DQWT_MOC_INCLUDE=1 -DQWT_NO_SVG -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB -I/home/denis/Documents/Projects/project-git/project/src/libs -I/opt/Qt/5.9.6/gcc_64/include -I/opt/Qt/5.9.6/gcc_64/include/QtConcurrent -I/opt/Qt/5.9.6/gcc_64/include/QtCore -I/opt/Qt/5.9.6/gcc_64/mkspecs/linux-g++ -I/home/denis/Documents/Projects/project-git/build-project-desktop-debug/qtc_Desktop_Qt_5_9_6_GCC_64bit_Debug/qwt.91a462ca/qt.headers -I/opt/Qt/5.9.6/gcc_64/include/QtGui -I/opt/Qt/5.9.6/gcc_64/include/QtOpenGL -I/opt/Qt/5.9.6/gcc_64/include/QtWidgets -I/opt/Qt/5.9.6/gcc_64/include/QtPrintSupport -I/opt/Qt/5.9.6/gcc_64/include/QtSvg -std=c++14 -o /home/denis/Documents/Projects/project-git/build-project-desktop-debug/qtc_Desktop_Qt_5_9_6_GCC_64bit_Debug/qwt.91a462ca/3a52ce780950d4d9/qwt_plot.cpp.o -c /home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp
In file included from /opt/Qt/5.9.6/gcc_64/include/QtCore/qmetatype.h:49:0,
from /home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot_item.h:14,
from /home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot_dict.h:15,
from /home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.h:14,
from /home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp:10:
/home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp: In function ‘void qwtEnableLegendItems(QwtPlot*, bool)’:
/opt/Qt/5.9.6/gcc_64/include/QtCore/qobjectdefs.h:271:35: error: initializer fails to determine size of ‘sig’
# define SIGNAL(a) qFlagLocation("2"#a QLOCATION)
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp:29:24: note: in expansion of macro ‘SIGNAL’
const char sig[] = SIGNAL(legendDataChanged(QVariant,QList<QwtLegendD ata>));
^~~~~~
/opt/Qt/5.9.6/gcc_64/include/QtCore/qobjectdefs.h:271:35: error: array must be initialized with a brace-enclosed initializer
# define SIGNAL(a) qFlagLocation("2"#a QLOCATION)
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp:29:24: note: in expansion of macro ‘SIGNAL’
const char sig[] = SIGNAL(legendDataChanged(QVariant,QList<QwtLegendD ata>));
^~~~~~
/opt/Qt/5.9.6/gcc_64/include/QtCore/qobjectdefs.h:270:35: error: initializer fails to determine size of ‘slot’
# define SLOT(a) qFlagLocation("1"#a QLOCATION)
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp:30:25: note: in expansion of macro ‘SLOT’
const char slot[] = SLOT(updateLegendItems(QVariant,QList<QwtLegendDat a>));
^~~~
/opt/Qt/5.9.6/gcc_64/include/QtCore/qobjectdefs.h:270:35: error: array must be initialized with a brace-enclosed initializer
# define SLOT(a) qFlagLocation("1"#a QLOCATION)
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/home/denis/Documents/Projects/project-git/project/src/libs/qwt/qwt_plot.cpp:30:25: note: in expansion of macro ‘SLOT’
const char slot[] = SLOT(updateLegendItems(QVariant,QList<QwtLegendDat a>));
^~~~
Process failed with exit code 1.

---

My env is:

* Ubuntu 18.04 LTS 64 bit
* GCC 7.3.0
* Qt official 5.9.6

PS: Hovewer on Windows it compiles successfully with MSVC2015 32-bit && Qt 5.9.6.

I compiled the file with your options on my box without problems, but on my box it is a gcc 7.3.1.

What happens, when changing the offending lines from:

Code:

---

const char sig[] = ...

---

to

Code:

---

const char* sig = ...

---

Or do you see another way to change the code to work around the compiler issue - bside writing the SIGNAL/SLOT signatures twice ?

Uwe

PS1: your compiler flags differ from those you find in qwtbuild.pri. At least -fno-math-errno -funsafe-math-optimizations should have an impact on the performance, when using methods from cmath. Also you should use a higher optimization level.
PS2: do you see an effect on your CPU usage, when enabling QwtPlotCurve::FilterPointsAggressive ?

> What happens, when changing the offending lines from:

Yes, many thanks, with:

Code:

---

const char* sig = ...

---

it is successfully compiled.

Weird - seems to be a compiler bug of gcc 7.3.0.

I will adjust the code - thanks for reporting,

Uwe

Quote:

---

Weird - seems to be a compiler bug of gcc 7.3.0.

---

Same happens and with ARM Linaro GCC 5.4.1, and with ARM GCC 6.3.

Quote:

---

PS1: your compiler flags differ from those you find in qwtbuild.pri. At least -fno-math-errno -funsafe-math-optimizations should have an impact on the performance, when using methods from cmath. Also you should use a higher optimization level.
PS2: do you see an effect on your CPU usage, when enabling QwtPlotCurve::FilterPointsAggressive ?

---

I have added QwtPlotCurve::FilterPointsAggressive for each of 8 curves and to add the -fno-math-errno -funsafe-math-optimizations with -O2, but nothing changes. The CPU load still stays in range 36-50% (on iMX6 with X11 && xcb backend).

PS: My plotting area has 1280x800 pixels, and updates every ~100 msec and has ~400 samples with each update.

---

Added after 40 minutes:

A high GPU loading ~40% stays even if I just periodically update the interest interval without of samples (when the X-axis with a grid moves left).

Quote:

---

Originally Posted by kuzulis

Same happens and with ARM Linaro GCC 5.4.1, and with ARM GCC 6.3.

---

I also tried the other gcc versions on my box ( f.e 6.2.1 ) without any problems. So it might be related to any of your compiler option. Maybe you can play with them - even if we already have a workaround it would be good to know where to be careful.

Quote:

---

Originally Posted by kuzulis

PS: My plotting area has 1280x800 pixels, and updates every ~100 msec and has ~400 samples with each update.

---

Oh boy - this is almost nothing and of course any sort of point reduction algos will have no effect when having almost no samples.

Concerning the raster paint engine: disabling antialiasing and using a pen width <= 1 are common ways to speed it up.

What numbers do you see when using a QOpenGLWidget instead of a QWidget with your test program you have posted to the devel mailing list. When running it with an update rate ~100ms you can at least see how much of it is related to Qwt. I would also try to run your test with an FBO and QImage to get an idea how much time the rendering takes and what is related to the rest of your graphics pipeline.

Uwe

Quote:

---

I also tried the other gcc versions on my box ( f.e 6.2.1 ) without any problems.

---

Yes, I'm too have no any issues using qmake projects. :)

Quote:

---

So it might be related to any of your compiler option.

---

I thought that need to use the GNU extension -std=gnu++xxx (maybe qmake uses it),
but results with QBS and this option is not success (same error).

But ok, I will use that workaround with const char*. :)

Quote:

---

What numbers do you see when using a QOpenGLWidget instead of a QWidget

---

I will try test it tomorrow...

Quote:

---

Originally Posted by kuzulis

I thought that need to use the GNU extension -std=gnu++xxx (maybe qmake uses it),
but results with QBS and this option is not success (same error).

---

This is not a matter of qmake vs. QBS. It is about compiling with different options and I would really like to know which of your compiler options is responsible.

Actually I already checked with the options that can be seen on your original posting - without running into a compiler error. So could you please play with these options by comparing them with those you get from the qmake build environment until we know. When removing "CONFIG += silent" from qwtbuild.pri you can see the usual build options.

Uwe

Quote:

---

What numbers do you see when using a QOpenGLWidget instead of a QWidget

---

I have checked following test example:

Code:

---

#include <QApplication>
#include <QOpenGLWidget>
#include <QPaintEvent>
#include <QPainter>
 
class Widget final : public QOpenGLWidget
{
public:
    explicit Widget(QWidget *parent = nullptr);
private:
    void paintEvent(QPaintEvent *event) final;
    void timerEvent(QTimerEvent *event) final;
};
 
Widget::Widget(QWidget *parent)
    : QOpenGLWidget(parent)
{
    startTimer(100);
}
 
void Widget::paintEvent(QPaintEvent *event)
{
    QPainter p(this);
 
    static bool toggled = false;
    const auto color = (toggled) ? QColor(Qt::red) : QColor(Qt::green);
    const auto rect = event->rect();
    p.fillRect(rect, color);
    toggled = !toggled;
}
 
void Widget::timerEvent(QTimerEvent *event)
{
    Q_UNUSED(event);
    update();
}
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    Widget w;
    w.setMinimumSize(1280, 800);
    w.show();
    return app.exec();
}

---

on iMX6 with Qt5 && X11 && xcb backend, and I got less than 2% of CPU loading (in non-optimized debug mode). Then I have speed up it to 50 msecs and I have same < 2%.

---

Added after 25 minutes:

But with this simple Qwt code I got ~50% CPU loading (as with "xcb'' and "eglfs" backends):

Code:

---

#include <QApplication>
#include <QDateTime>
#include <QPen>
#include <QTimer>
 
#include <qwt/qwt_interval.h>
#include <qwt/qwt_plot.h>
#include <qwt/qwt_plot_grid.h>
#include <qwt/qwt_plot_opengl_canvas.h>
#include <qwt/qwt_scale_draw.h>
#include <qwt/qwt_text.h>
 
class TimeScaleDraw final : public QwtScaleDraw
{
private:
    QwtText label(double v) const final;
};
 
QwtText TimeScaleDraw::label(double v) const
{
    const auto dt = QDateTime::fromMSecsSinceEpoch(qint64(v));
    const auto text = dt.time().toString();
    return text;
}
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    QwtPlot plot;
 
    const auto canvas = new QwtPlotOpenGLCanvas;
    canvas->setCursor(QCursor());
    canvas->setFrameStyle(QFrame::NoFrame);
    plot.setCanvas(new QwtPlotOpenGLCanvas);
 
    const auto grid = new QwtPlotGrid;
    grid->enableXMin(true);
    grid->setMajorPen(QPen(Qt::gray, 0, Qt::DotLine));
    grid->setMinorPen(QPen(Qt::gray, 0, Qt::DotLine));
    grid->attach(&plot);
 
    // Configure X-axis.
    const auto xScaleDraw = new TimeScaleDraw;
    plot.setAxisScaleDraw(QwtPlot::xBottom, xScaleDraw);
    const QwtText xAxisName(QObject::tr("Time"), QwtText::PlainText);
    plot.setAxisTitle(QwtPlot::xBottom, xAxisName);
    plot.setAxisLabelAlignment(QwtPlot::xBottom, Qt::AlignCenter | Qt::AlignBottom);
 
    // Configure Y-axis
    plot.setAxisScale(QwtPlot::yLeft, 0, 65535);
    const QwtText yAxisName(QObject::tr("RAW"), QwtText::PlainText);
    plot.setAxisTitle(QwtPlot::yLeft, yAxisName);
 
    QTimer timer;
    QObject::connect(&timer, &QTimer::timeout, [&]() {
 
        const auto kWindowInterval = 20000; // 20 seconds
        const auto maximum = QDateTime::currentMSecsSinceEpoch();
        const auto minimum = maximum - kWindowInterval;
 
        plot.setAxisScale(QwtPlot::xBottom, minimum, maximum);
        plot.replot();
    });
 
    timer.start(100);
    plot.showFullScreen();
 
    return app.exec();
}

---

But, in this case I have a black color of OpenGL canvas by unknown reason.

Well the plot example has to paint the axes and the grid for each frame. The grid lines are done by the OpenGL paint engine, while the axes are done by raster.
So you could check what happens, when using no grid lines or when using a solid pen. Another check might be to disable the tick labels ( QwtAbstractScaleDraw::enableComponent ) - rendering text is an expensive operation.

Uwe

The black content might be related to the fact, that your code creates 2 OpenGl canvases ?

Quote:

---

The black content might be related to the fact, that your code creates 2 OpenGl canvases ?

---

Where is two OpenGl canvases ?

Quote:

---

The grid lines are done by the OpenGL paint engine, while the axes are done by raster.

---

What if try to derive the QwtPlot from the QOpenGLWidget?

UPD: When I have replaced the QFrame with QOpenGLWidget (it is QwtPlot deriving) then I got a funny colored plotting with all rainbow and also the CPU loading ~12% instead of previous ~0% on Windows.

Quote:

---

Where is two OpenGl canvases ?.

---

The posted code creates a canvas, but the setCanvas call assigns a second one also created by new.

Quote:

---

What if try to derive the QwtPlot from the QOpenGLWidget?[

---

QwtPlot is a composite widget, that consists of other widgets: title/footer + 4 scales + canvas + legend ( usually with widgets as legend items ).

So all of them need to be derived from QOpenGLWidget, what is only possible by patching Qwt code.
You might also need to replace some QPixmaps by QOpenGLFramebufferObjects.

Before working on qskinny ( https://github.com/uwerat/qskinny ) I played with the idea of a widget library on top of QOpenGLWidget to get the benefits of hardware accelerated graphics without suffering from the downsides of JavaScript. But I had to give up because of fundamental problems: see https://bugreports.qt.io/browse/QTBUG-50916.

But using the OpenGl paint engine does not mean, that everything is hardware accelerated. OpenGL does not support the complete set of primitives you can define with QPainter and the process of translating them to something OpenGL can handle is done by the CPU. F.e I once compared rendering our SVG icons to a QImage + translating it to a FBO, with another implementation, that painted directly to the FBO using the OpenGL paint engine ( see https://github.com/uwerat/qskinny/bl.../Benchmark.cpp ). At that time the second implementation was not faster, what might indicate, that the tesselation took almost the same time as the actual rendering.

That said: it's worth to check if the text labels or creating the dots are a factor.

Uwe

Quote:

---

The posted code creates a canvas, but the setCanvas call assigns a second one also created by new.

---

Oops.. But in result (after I fixed this), the canvas area still is black.

Quote:

---

That said: it's worth to check if the text labels or creating the dots are a factor.

---

When I have disabled the grid creation:

Code:

---

//    const auto grid = new QwtPlotGrid;
//    grid->enableXMin(true);
//    grid->setMajorPen(QPen(Qt::gray, 0, Qt::DotLine));
//    grid->setMinorPen(QPen(Qt::gray, 0, Qt::DotLine));
//    grid->attach(&plot);

---

or to use a solid grid lines:

Code:

---

const auto grid = new QwtPlotGrid;
    grid->enableXMin(true);
    grid->setMajorPen(QPen(Qt::gray, 0, Qt::SolidLine));
    grid->setMinorPen(QPen(Qt::gray, 0, Qt::SolidLine));
    grid->attach(&plot);

---

the CPU load decreased from ~50% to ~36%. But I don't see those grid lines anyway, as my canvas is black.

Quote:

---

QwtPlot is a composite widget, that consists of other widgets: title/footer + 4 scales + canvas + legend ( usually with widgets as legend items ).

---

Yes, then I try to replace this elements to QOpenGLWidget sequentially, maybe it will be enough to replace the scales only.

---

Added after 11 minutes:

Quote:

---

Yes, then I try to replace this elements to QOpenGLWidget sequentially, maybe it will be enough to replace the scales only.

---

Sadly.. It does not work at all.. I got a colored artifacts and a huge ~10% CPU load even on Windows (even if I comments out the

Code:

---

QwtScaleWidget::paintEvent()

---

method).

Attachment 12960

UPD2: Most likelly, I need to get rid from Qwt && QtWidgets and try to port my app to Quick2 where I need try to create an own graphics library... ((( Besides, my application crashes at using painter.drawText() with OpenGL widget on IMX6.. ((( Seems it is some bug in OpenGL driver or something else.

Uwe, many thanks anyway!

Quote:

---

Originally Posted by kuzulis

Most likelly, I need to get rid from Qwt && QtWidgets and try to port my app to Quick2 where I need try to create an own graphics library...

---

Well you have a working application running the xcb platform using QwtPlotOpenGLCanvas and you might also have the option of using EGLFS with QwtPlotCanvas::OpenGLBuffer ( you didn't report any results with this combination so far ).

Furthermore you found out, that calculating the dots for your grid is responsible for ~25% of your CPU load I guess the rest is used for creating the glyphs for the text labels.

So your simple option is to go with solid grid lines and maybe finding a workaround for the texts - nobody can read labels that are changing 10 times a second. Drawing the curves should be fast and I would expect, that your requirement of 400 points is no problem, when drawing with a solid line. F.e. you could change your plot in a way that you have a stable coordinate system by using an axis always going from [-10,0] - indicating the time until now. This way you can avoid having to repaint the expensive parts for each update.

Don't expect that Qt/Quick offers you any faster implementation for this - there is not even a public C++ APIs for simple stuff like rendering text. Even worse all kind of primitives have to be heavy QQuickItems and the only way to access them is by Javascript. But I would even say that for an oscilloscope the scene graph does not buy you anything.

So if you really want to start your own graphics library better do it using native OpenGL ( see https://doc.qt.io/qt-5/qopenglwidget.html#paintGL ).

If you are interested you could also have a look at https://github.com/QUItCoding/qnanopainter. I have not tested it myself, but from what I read it seems to outperform the corresponding implementations you find in Qt.

Uwe

For the record: it turned out, that the X11 paint engine has been reintroduced with Qt 5.10. It can be enabled by setting "export QT_XCB_NATIVE_PAINTING=1".
Doing a few tests it looks like it works with Qwt as good as with Qt4/X11.

This is a good ( AFAIK the only existing one for Qt5 ) option, for running QWidget applications with a hardware accelerated graphics pipeline.
Not to mention, that it is the only implementation, that offers satisfying results for running QWidget applications on remote desktops.

Uwe

Hi Uwe,

seems that the QT_XCB_NATIVE_PAINTING=1 option has not effect to me.

I have created a simple test app as before (with usual widget and 50 msecs timer),
where I have added the additional drawText() function:

Code:

---

void Widget::paintEvent(QPaintEvent *event)
{
    QPainter p(this);
 
    static bool toggled = false;
 
    const auto c = toggled ? Qt::red : Qt::green;
    p.save();
    p.fillRect(event->rect(), QColor(c));
    p.restore();
 
    p.save();
    p.drawText(event->rect().center(), tr("FOOOOOO"));
    p.restore();
 
    toggled = !toggled;
}

---

And the results are following:

== without of drawText ==

XCB/X11 (with/without QT_XCB_NATIVE_PAINTING) => CPU usage ~3.6%
EFLFS => CPU usage ~92%

== with drawText ==

XCB/X11 (with/without QT_XCB_NATIVE_PAINTING) => CPU usage ~36%
EFLFS => CPU usage ~100%

Summary, so, you are right. The drawText() takes a lot of CPU time, the CPU usage is in ~10 times more..

Also I have added your proposal to get a paint engine type to my paint event:

Code:

---

void Widget::paintEvent(QPaintEvent *event)
{
...
    const auto type = p.paintEngine()->type();
    qDebug() << "Type:" << type;
...
}

---

And I always get the 0 as with and as without of QT_XCB_NATIVE_PAINTING (with XCB/X11 backend).
So, seems, the "native X11" acceleration is accepted, but it does not help much...

UPD: If try to use the QQuickPaintedItem class with the QtQuick application, then it is even worse than with the QtWidgets:

XCB/X11 (with/without QT_XCB_NATIVE_PAINTING) => CPU usage ~100%
EFLFS => CPU usage ~100%

---

Added after 56 minutes:

Uwe,

seems, that:

Code:

---

...
canvas->setPaintAttribute(QwtPlotCanvas::BackingStore, false);
...

---

helpes a bit... it decreased the CPU usage from 65% to 30%...

and adding this:

Code:

---

...
canvas->setPaintAttribute(QwtPlotCanvas::OpenGLBuffer, true);
...

---

decreases even more up to ~26%..
Is any other tricks to improve the Qwt performance?

IMO the CPU is mostly spent on creating the glyphs for the text, what is always done by the CPU - and the part, that is needed to for drawing them later is less important.

By using QQuickPaintedItem you are still using QPainter and don't enter the path for rendering texts with Qt/Quick. If you want to check that one you need to use QQuickText - what is not so easy without doing QML.
For your test code it would have a significant effect as you don't change the text and the existing scene graph nodes do not need to be recreated. This is not different to an implementation, where
drawing the text to a pixmap - once in the beginning - and use it with each update.

But this is not the situation of your application, where you change the labels for each update and you have to recreate the glyph nodes too.

But for drawing the curves/grid etc you will see a significant effect with using a hardware accelerated graphic stack - like with the X11 paint engine. Maybe disable the tick labels ( QwtAbstractScaleDraw::enableComponent ) and do some checks with your real application. Maybe you can compare it with one of the solutions using opengl paint engine - it might be interesting to know if creating the dots for the grid lines differs.

Out of interest: what happens, when using QStaticText instead of QString ?

Uwe

> Out of interest: what happens, when using QStaticText instead of QString ?


I get same ~36% with drawStaticText() as with drawText().

> Maybe disable the tick labels ( QwtAbstractScaleDraw::enableComponent ) and do some checks with your real application.

It is not an option for me.. :(

But, many thanks, anyway.

UPD:

It is interest, that when I use the QCP, then CPU usage is ~18%, but with Qwt is %25% in following tests:

== QCP ==

Code:

---

#include <QApplication>
#include <QDateTime>
#include <QFont>
#include <QFontDatabase>
#include <QPen>
#include <QTimer>
 
#include <qcp/qcustomplot.h>
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-B.ttf"));
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-BI.ttf"));
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-R.ttf"));
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-RI.ttf"));
 
    const QFont font(QLatin1String("Ubuntu Mono"));
    QApplication::setFont(font);
 
    QCustomPlot plot;
    //plot.setOpenGl(true, 0);
 
    QTimer timer;
    QObject::connect(&timer, &QTimer::timeout, [&]() {
 
        const auto kWindowInterval = 20000; // 20 seconds
        const auto maximum = QDateTime::currentMSecsSinceEpoch();
        const auto minimum = maximum - kWindowInterval;
 
        QCPRange range(minimum, maximum);
 
        plot.xAxis->setRange(range);
        plot.replot();
    });
 
    timer.start(100);
 
    plot.showFullScreen();
 
    return app.exec();
}

---

== QWT ==

Code:

---

#include <QApplication>
#include <QDateTime>
#include <QFont>
#include <QFontDatabase>
#include <QPen>
#include <QTimer>
 
#include <qwt/qwt_interval.h>
#include <qwt/qwt_plot.h>
#include <qwt/qwt_plot_grid.h>
#include <qwt/qwt_plot_canvas.h>
#include <qwt/qwt_scale_draw.h>
#include <qwt/qwt_text.h>
#include <qwt/qwt_scale_widget.h>
 
class TimeScaleDraw final : public QwtScaleDraw
{
private:
    QwtText label(double v) const final;
};
 
QwtText TimeScaleDraw::label(double v) const
{
    const auto dt = QDateTime::fromMSecsSinceEpoch(qint64(v));
    const auto text = dt.time().toString();
    return text;
}
 
class Plot : public QwtPlot
{
    Q_OBJECT
public:
    explicit Plot(QWidget *parent = nullptr);
 
private slots:
    void updatePlot();
 
private:
    QTimer *m_timer = nullptr;
};
 
Plot::Plot(QWidget *parent)
    : QwtPlot(parent)
{
    setAutoReplot(false);
 
    const auto canvas = new QwtPlotCanvas;
    canvas->setPaintAttribute(QwtPlotCanvas::BackingStore, false);
    canvas->setPaintAttribute(QwtPlotCanvas::Opaque, true);
    canvas->setPaintAttribute(QwtPlotCanvas::OpenGLBuffer, true);
    canvas->setCursor(QCursor());
    canvas->setFrameStyle(QFrame::NoFrame);
    setCanvas(canvas);
 
    const auto grid = new QwtPlotGrid;
    grid->enableXMin(true);
    grid->setMajorPen(QPen(Qt::gray, 0, Qt::DotLine));
    grid->setMinorPen(QPen(Qt::gray, 0, Qt::DotLine));
    grid->attach(this);
 
    // Configure X-axis.
    const auto xScaleDraw = new TimeScaleDraw;
    setAxisScaleDraw(QwtPlot::xBottom, xScaleDraw);
    const QwtText xAxisName(QObject::tr("Time"), QwtText::PlainText);
    setAxisTitle(QwtPlot::xBottom, xAxisName);
    setAxisLabelAlignment(QwtPlot::xBottom, Qt::AlignCenter | Qt::AlignBottom);
 
    // Configure Y-axis
    setAxisScale(QwtPlot::yLeft, 0, 65535);
    const QwtText yAxisName(QObject::tr("RAW"), QwtText::PlainText);
    setAxisTitle(QwtPlot::yLeft, yAxisName);
 
    m_timer = new QTimer(this);
    connect(m_timer, SIGNAL(timeout()), this, SLOT(updatePlot()));
 
    m_timer->start(100);
}
 
void Plot::updatePlot()
{
    const auto kWindowInterval = 20000; // 20 seconds
    const auto maximum = QDateTime::currentMSecsSinceEpoch();
    const auto minimum = maximum - kWindowInterval;
 
    setAxisScale(QwtPlot::xBottom, minimum, maximum);
    replot();
}
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-B.ttf"));
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-BI.ttf"));
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-R.ttf"));
    QFontDatabase::addApplicationFont(QLatin1String(":/fonts/UbuntuMono-RI.ttf"));
 
    const QFont font(QLatin1String("Ubuntu Mono"));
    QApplication::setFont(font);
 
    Plot plot;
    plot.showFullScreen();
 
    return app.exec();
}
 
#include "qwt_rendering.moc"

---

But it is not a big differences, related to implementation details...

Quote:

---

> Maybe disable the tick labels ( QwtAbstractScaleDraw::enableComponent ) and do some checks with your real application.
It is not an option for me.. :(

---

This was for finding out the costs of the labels - not to be the solution for your plot.

But in the end you only have 2 options: reduce how often you repaint the tick labels
or accept the CPU load.

At some point you have to accept, that you have to adjust your application to your system and a solution would be simple: use a scale with a range of [-10s, 0] and let your curve be moving from right to left.

Quote:

---

It is interest, that when I use the QCP, ...

---

Comparing an empty plot with one, that draws a grid with dotted lines does not mean much.
Consider, that f.e the raster paint engine has to calculate and pixel down all dots one by one and we also expected, that this part is responsible for the high CPU load of the OpenGL paint engine.

Uwe

Quote:

---

At some point you have to accept, that you have to adjust your application to your system and a solution would be simple: use a scale with a range of [-10s, 0] and let your curve be moving from right to left.

---

I'm don't understand a bit, how I can do it?

My every sample contains in the 'X' dimension some timestamp in milliseconds. So, there are a big numbers...

So, how it will work if I try to set the fixed axis scale:

Code:

---

...
setAxisScale(QwtPlot::xBottom, -10, 0);
...

---

? I don't understand... :(

Have a look at: http://qwt.sourceforge.net/class_qwt_series_data.html and http://qwt.sourceforge.net/class_qwt...05dfae2d1668e6

The implementation could be like this:

Code:

---

virtual QPointF YourData::sample( size_t  index )  const
{
    qreal currentX = ...;
    qreal x = ...;
    qreal y = ...;
 
    return QPointF( x - currentX, y );
}

---

This translates "ms since being started" into "ms before now" and you can set a range of [-10000, 0] to always see the samples of the last 10 seconds.
Be careful, that calculating x/y/currentX is not expensive - in case you need to render many points ( many more than 400 isn't ).

In case of having many points outside of the 10s ( or whatever your frame is ) it might be worth to enable polygon clipping.

Uwe

Uwe, many thanks, I will try it.

Uwe,

Code:

---

virtual QPointF YourData::sample( size_t  index )  const
    {
        ...
        qreal currentX = ...;
        ...
    }

---

Are you sure that this will not a bootleneck too? Because for this situation we need to call the QDateTime::currentDatetime() each time for each sample...

Quote:

---

Originally Posted by kuzulis

Because for this situation we need to call the QDateTime::currentDatetime() each time for each sample...

---

Of course you have to calculate your reference time only once and not for each call of sample().
So what about storing QDateTime::currentDatetime() as reference time inside of the data object, whenever you receive a new set of samples.

You could also rely on the fact, that iterating over samples always starts at index 0 and always update the reference time on this one.
But I wouldn't recommend to do this, as you always have a delay until the plot is updated and then you have a gap between the data and the reference time.

Uwe

Uwe,

So, your idea is to calculate the reference time like this:

e.g.:

Code:

---

...
 
MySeriesData : public QwtSeriesData
{
...
    MySeriesData (qint64 reftime, const QVector<QPointF> &samples) 
        : m_reftime(reftime)
        , m_samples(samples)
    {
    }
 
    QPointF sample(size_t  index)  const
    {
        ...
        ...
        return QPointF(x - m_reftime, y);
    }
 
private:
    qint64 m_reftime= 0;
    QVector<QPointF> m_samples;
}
...
 
// And then...
const auto reftime = QDateTime::currentMSecsSinceEpoch();
curve->setData(new MySeriesData(reftime, samples));
..

---

?

Well, m_reftime is a qint64, while the samples are doubles. But as long as they match, why not.

Uwe