Discussion:
iMX6 EGLGS 2D (QtWidgets) painting acceleration
(too old to reply)
Denis Shienkov
2018-08-29 09:39:24 UTC
Permalink
Hi all.

I have an Apalis iMX6 board with the Yocto's image with the working 'eglfs'
and 'linuxfb' backends (without of X11 support).

I need to create a 'pure' QtWidgets application, where I need to use a
real-time plotting with the Qwt library (using the Qt Quick is not an
option, as there the QtCharts is not ready for usage) .

But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as with
the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable,
because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading.

Is any workarounds for this? Maybe I need to re-build the Yocto's image to
enable the X11 'xcb' support?

BR,
Denis
Denis Shienkov
2018-08-29 10:21:18 UTC
Permalink
I even have created a simple test app, which re-fill the 1280x800 rect
every 50 msec with the 'red' and 'green' colors.

[code]

#include <QApplication>

#include <QWidget>

#include <QPaintEvent>

#include <QPainter>


class Widget final : public QWidget

{

public:

explicit Widget(QWidget *parent = nullptr);

private:

void paintEvent(QPaintEvent *event) final;

void timerEvent(QTimerEvent *event) final;

};


Widget::Widget(QWidget *parent)

: QWidget(parent)

{

startTimer(50);

}


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

}

[/code]

And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 has
~50% CPU load. WTF?

BR,
Denis
Post by Denis Shienkov
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the working
'eglfs' and 'linuxfb' backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to use a
real-time plotting with the Qwt library (using the Qt Quick is not an
option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as
with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable,
because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's image to
enable the X11 'xcb' support?
BR,
Denis
drwho
2018-08-29 12:51:36 UTC
Permalink
Hi Denis,

Most Qt widgets are not drawn using opengl but instead are rasterized. 
I was surprised when I first learned this as well.

"QPainter <http://doc.qt.io/qt-5/qpainter.html> provides API for drawing
vector graphics, text and images onto different surfaces, or
QPaintDevice <http://doc.qt.io/qt-5/qpaintdevice.html> instances, such
as QImage <http://doc.qt.io/qt-5/qimage.html>, QOpenGLPaintDevice
<http://doc.qt.io/qt-5/whatsnew50.html#qopenglpaintdevice>, QWidget
<http://doc.qt.io/qt-5/qwidget.html>, and QPrinter
<http://doc.qt.io/qt-5/qprinter.html>. The actual drawing happens in the
QPaintDevice <http://doc.qt.io/qt-5/qpaintdevice.html>'s QPaintEngine
<http://doc.qt.io/qt-5/qpaintengine.html>. The software rasterizer and
the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine
<http://doc.qt.io/qt-5/qpaintengine.html> implementations. *The raster
paint engine is Qt’s software rasterizer, and is used when drawing on a
QImage <http://doc.qt.io/qt-5/qimage.html> or QWidget
<http://doc.qt.io/qt-5/qwidget.html>.* Its strength over the OpenGL
paint engine is its high quality when antialiasing is enabled, and a
complete feature set.”
Post by Denis Shienkov
I even have created a simple test app, which re-fill the 1280x800 rect
every 50 msec with the 'red' and 'green' colors.
[code]
#include<QApplication>
#include<QWidget>
#include<QPaintEvent>
#include<QPainter>
classWidgetfinal:publicQWidget
{
explicitWidget(QWidget*parent=nullptr);
voidpaintEvent(QPaintEvent*event)final;
voidtimerEvent(QTimerEvent*event)final;
};
Widget::Widget(QWidget*parent)
:QWidget(parent)
{
startTimer(50);
}
voidWidget::paintEvent(QPaintEvent*event)
{
QPainterp(this);
staticbooltoggled=false;
constautocolor=(toggled)?QColor(Qt::red):QColor(Qt::green);
constautorect=event->rect();
p.fillRect(rect,color);
toggled=!toggled;
}
voidWidget::timerEvent(QTimerEvent*event)
{
Q_UNUSED(event);
update();
}
intmain(intargc,char*argv[])
{
QApplicationapp(argc,argv);
Widgetw;
w.setMinimumSize(1280,800);
w.show();
returnapp.exec();
}
[/code]
And then I see that the Desktop PC has the ~0% CPU load, but the iMX6
has ~50% CPU load. WTF?
BR,
Denis
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the
working 'eglfs' and 'linuxfb'  backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to
use a real-time plotting with the Qwt library (using the Qt Quick
is not an option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU
loading as with the 'eglfs' and as with 'linuxfb' backends. It is
not an acceptable, because, e.g. on Desktop Linux/Windows it takes
~4-5% CPU loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's
image to enable the X11 'xcb' support?
BR,
Denis
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Denis Shienkov
2018-08-29 13:43:40 UTC
Permalink
Most Qt widgets are not drawn using opengl but instead are rasterized. I
was surprised when I first learned this as well.

So, there are no way to improve an acceleration and to minimize the CPU
loading?

PS: I tried to mix the OpenGL widgets with usual widgets, but the 'eglfs'
says that it is impossible to mix it. This is some sort of hopeless
situation. (((

BR,
Denis
Hi Denis,
Most Qt widgets are not drawn using opengl but instead are rasterized. I
was surprised when I first learned this as well.
"QPainter <http://doc.qt.io/qt-5/qpainter.html>
<http://doc.qt.io/qt-5/qpainter.html> provides API for drawing vector
graphics, text and images onto different surfaces, or QPaintDevice
<http://doc.qt.io/qt-5/qpaintdevice.html>
<http://doc.qt.io/qt-5/qpaintdevice.html> instances, such as QImage
<http://doc.qt.io/qt-5/qimage.html> <http://doc.qt.io/qt-5/qimage.html>,
QOpenGLPaintDevice
<http://doc.qt.io/qt-5/whatsnew50.html#qopenglpaintdevice>
<http://doc.qt.io/qt-5/whatsnew50.html#qopenglpaintdevice>, QWidget
<http://doc.qt.io/qt-5/qwidget.html> <http://doc.qt.io/qt-5/qwidget.html>,
and QPrinter <http://doc.qt.io/qt-5/qprinter.html>
<http://doc.qt.io/qt-5/qprinter.html>. The actual drawing happens in the
QPaintDevice <http://doc.qt.io/qt-5/qpaintdevice.html>
<http://doc.qt.io/qt-5/qpaintdevice.html>'s QPaintEngine
<http://doc.qt.io/qt-5/qpaintengine.html>
<http://doc.qt.io/qt-5/qpaintengine.html>. The software rasterizer and
the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine
<http://doc.qt.io/qt-5/qpaintengine.html>
<http://doc.qt.io/qt-5/qpaintengine.html> implementations. *The raster
paint engine is Qt’s software rasterizer, and is used when drawing on a
QImage <http://doc.qt.io/qt-5/qimage.html>
<http://doc.qt.io/qt-5/qimage.html> or QWidget
<http://doc.qt.io/qt-5/qwidget.html> <http://doc.qt.io/qt-5/qwidget.html>.*
Its strength over the OpenGL paint engine is its high quality when
antialiasing is enabled, and a complete feature set.”
I even have created a simple test app, which re-fill the 1280x800 rect
every 50 msec with the 'red' and 'green' colors.
[code]
#include <QApplication>
#include <QWidget>
#include <QPaintEvent>
#include <QPainter>
class Widget final : public QWidget
{
explicit Widget(QWidget *parent = nullptr);
void paintEvent(QPaintEvent *event) final;
void timerEvent(QTimerEvent *event) final;
};
Widget::Widget(QWidget *parent)
: QWidget(parent)
{
startTimer(50);
}
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();
}
[/code]
And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 has
~50% CPU load. WTF?
BR,
Denis
Post by Denis Shienkov
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the working
'eglfs' and 'linuxfb' backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to use a
real-time plotting with the Qwt library (using the Qt Quick is not an
option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as
with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable,
because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's image
to enable the X11 'xcb' support?
BR,
Denis
_______________________________________________
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2018-08-29 15:18:15 UTC
Permalink
Post by drwho
Most Qt widgets are not drawn using opengl but instead are rasterized. I
was surprised when I first learned this as well.
So, there are no way to improve an acceleration and to minimize the CPU
loading?
Rewrite using techniques and classes that are accelerated using OpenGL. Like
QtQuick.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-08-30 07:44:21 UTC
Permalink
Post by Denis Shienkov
So, there are no way to improve an acceleration and to minimize the CPU
loading?
It depends on the requirements of your application, but when it comes to
oscilloscope alike widgets your best choice is Qt4/X11.

The X11 paint engine is hardware accelerated, it even allows painting
outside of paint events - what is important for incremental painting.

( The fact, that Qt 4.8 prefers using raster with the argument of
performance it is totally nonsense, when it comes to any sort of vector
graphics. )

Furthermore the X11 paint engine simply has a better quality. The sort of
bugs coming and going with the various Qt versions is a nightmare for any
sort of graphics framework. Actually my job for today is to find a work
around for this one: https://bugreports.qt.io/browse/QTBUG-70101

--

If you need to go with Qt5 I would recommend to use a platform that
allows for using QOpenGlWidget - X11 again is IMHO not a bad choice.
Actually one of our terminals is a iMX6, where we do this ( because we
needed VNC support ).

Next I recommend Qwt from SVN trunk, where you can simply assign a
QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the
OpenGL paint engine is not as good as X11 or Raster, but for a
oscilloscope things usually do not need to be pixel perfect.

--

Finally you should not ignore algorithmic options to reduce what has to
be painted. How to optimize the rendering process is often quite
individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt
6.2 ) has a significant effect in oscilloscope alike applications.

In fact I have been contacted quite often with oscilloscope applications
struggling with performance issues and often it could be solved on a
algorithmic level.

As an inspiration you could also try to run the oscilloscope demo of Qwt
on your board. You will notice, that it runs with almost no CPU usage
because it mostly paints incrementally. Of course this only works because
the design of the user interface is made for this, but maybe you can do
something similar.

Uwe
Denis Shienkov
2018-08-30 11:26:34 UTC
Permalink
Hi Uwe,

many thanks for your help! :)

Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and
QwtPlotOpenGLCanvas
does help a bit. The iMX6 CPU usage now is ~50% (instead of previous 100%).

PS: But compilation for latest Qwt version from trunk r2921 fails, please
look on this my post:
https://www.qtcentre.org/threads/69743-Qwt-6-3-0-(from-qwt-code-r2921-trunk)-compilation-fails-on-Ubuntu-18-04?p=303603#post303603

BR,
Denis
Post by Uwe Rathmann
Post by Denis Shienkov
So, there are no way to improve an acceleration and to minimize the CPU
loading?
It depends on the requirements of your application, but when it comes to
oscilloscope alike widgets your best choice is Qt4/X11.
The X11 paint engine is hardware accelerated, it even allows painting
outside of paint events - what is important for incremental painting.
( The fact, that Qt 4.8 prefers using raster with the argument of
performance it is totally nonsense, when it comes to any sort of vector
graphics. )
Furthermore the X11 paint engine simply has a better quality. The sort of
bugs coming and going with the various Qt versions is a nightmare for any
sort of graphics framework. Actually my job for today is to find a work
around for this one: https://bugreports.qt.io/browse/QTBUG-70101
--
If you need to go with Qt5 I would recommend to use a platform that
allows for using QOpenGlWidget - X11 again is IMHO not a bad choice.
Actually one of our terminals is a iMX6, where we do this ( because we
needed VNC support ).
Next I recommend Qwt from SVN trunk, where you can simply assign a
QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the
OpenGL paint engine is not as good as X11 or Raster, but for a
oscilloscope things usually do not need to be pixel perfect.
--
Finally you should not ignore algorithmic options to reduce what has to
be painted. How to optimize the rendering process is often quite
individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt
6.2 ) has a significant effect in oscilloscope alike applications.
In fact I have been contacted quite often with oscilloscope applications
struggling with performance issues and often it could be solved on a
algorithmic level.
As an inspiration you could also try to run the oscilloscope demo of Qwt
on your board. You will notice, that it runs with almost no CPU usage
because it mostly paints incrementally. Of course this only works because
the design of the user interface is made for this, but maybe you can do
something similar.
Uwe
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Uwe Rathmann
2018-08-30 13:09:22 UTC
Permalink
Post by Denis Shienkov
Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and
QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50%
(instead of previous 100%).
I have been attending one of the Qt roadshows last year in Munich. One of
the speakers asked the audience which Qt versions they are using:

I didn't have time to count them manually, but my rough estimation was
that about 30% were still on Qt4. Assuming that almost all of them were
Qt/Widgets users and there are others in the Qt5 groups I would guess
that the majority was interested in Qt/Widget applications.

Considering, that Qt/Quick Controls 1 has been given up it is fair to say
that today the only reasonable option, Qt has to offer for desktop
applications, is: Qt/Widgets. So to me there is an obvious mismatch
between where the users are and what Qt development is working on.

Concerning the future of Qt/Widgets I guess almost everyone wants to have
hardware accelerated options - like what we had with Qt4/X11 or what
could be done with OpenGL.

The most recent related feature I'm aware of was introducing QOpenGLWidget
with Qt 5.4. But combining QOpenGLWidget with standard QWidgets is
unstable - see https://bugreports.qt.io/browse/QTBUG-50916 ).

Furthermore nobody seems to be interested in working on the OpenGL paint
engine. At least I have no explanation, why bugs like this one https://
bugreports.qt.io/browse/QTBUG-52672 are not being handled over years.
( actually this one is assigned to Gunnar, who is not even active anymore
).

From my experience with the QSkinny project I'm tempted to say that it
would even be possible to implement the Qt/Widgets API on top of Qt/Quick
core. Of course it wouldn't be exactly the same, but for standard desktop
applications it should be possible to offer a migration path, that is not
harder than what we had with Qt3 -> Qt4.

Uwe
Thiago Macieira
2018-08-30 14:50:41 UTC
Permalink
Post by Uwe Rathmann
Furthermore nobody seems to be interested in working on the OpenGL paint
engine
That paint engine was always experimental and the experiment concluded. There
were two important conclusions:
a) retrofitting paint events on top of OpenGL is hard and not efficient, plus
it was not pixel-perfect
b) proper OpenGL integration requires a stack designed with OpenGL in mind

The result of (b) is a retained-mode scene graph. It's in the QtQuick library.
Post by Uwe Rathmann
From my experience with the QSkinny project I'm tempted to say that it
would even be possible to implement the Qt/Widgets API on top of Qt/Quick
core.
So long as you ditch the paint event for most of the classes, leaving the
QQuickPaintedItem (or whatever it's called) only for the cases where it's
truly needed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-08-30 15:46:32 UTC
Permalink
Post by Thiago Macieira
The result of (b) is a retained-mode scene graph. It's in the QtQuick library.
I know, but now we have Qt 5.11 and it is fair to review this result:

the API of the scene graph - as it is today - is so far from offering a
comparable feature set like the one you have with QPainter. Actually it
does not even offer the most fundamental primitives like:

- non rectangular boxes
- text
- ...

Have a look at all classes in the public API being derived from QSGNode:
it boils down to QSGImageNode, QSGRectangleNode, QSGSimpleRectNode and
QSGSimpleTextureNode. Do you really recommend starting with only this ?

All sort of code that implements the minimal set of primitives almost
everyone needs is hidden somewhere in private code of Qt/Quick core. But
even if this code would make it into the scene graph it would be far from
what you get with QPainter.

But QPainter is more: it is an API, that allows you to implement render
engines that works with different backends - f.e PDF is often simply
mandatory. So implementing a plot package on top of scene graph does not
mean, that you can drop the QPainter code you have to do the work twice.

Having the common API running on various backends is such a huge asset of
Qt - maybe one of the most important ones Qt has to offer. I really don't
get why so many Qt developers do not realize what you actually have in
your hands.

Uwe
Thiago Macieira
2018-08-30 22:47:34 UTC
Permalink
Post by Uwe Rathmann
Post by Thiago Macieira
The result of (b) is a retained-mode scene graph. It's in the QtQuick library.
the API of the scene graph - as it is today - is so far from offering a
comparable feature set like the one you have with QPainter. Actually it
- non rectangular boxes
Draw it with OpenGL.
Post by Uwe Rathmann
- text
Implemented in QML. Just layer your text over whatever you were painting as a
background.
Post by Uwe Rathmann
- ...
Use the onion solution: layers!
Post by Uwe Rathmann
But QPainter is more: it is an API, that allows you to implement render
engines that works with different backends - f.e PDF is often simply
mandatory. So implementing a plot package on top of scene graph does not
mean, that you can drop the QPainter code you have to do the work twice.
PDF is not OpenGL. Trying to solve for both makes it a good solution for
neither.
Post by Uwe Rathmann
Having the common API running on various backends is such a huge asset of
Qt - maybe one of the most important ones Qt has to offer. I really don't
get why so many Qt developers do not realize what you actually have in
your hands.
I understand it's a huge asset. But it's also a performance bottleneck.

You can always just use QPainter on a QPixmap and paint that pixmap on your
QSGPaintedItem. It won't be particularly fast, but it will work and do what
you asked.

If you want faster, redesign with OpenGL in mind.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-09-02 12:42:47 UTC
Permalink
Post by Thiago Macieira
You can always just use QPainter on a QPixmap and paint that pixmap on
your QSGPaintedItem. It won't be particularly fast, but it will work and
do what you asked.
After some conversation with Denis: the use case of this thread is a
oscilloscope - drawing a polyline with ~400 points, 10 times a second.

It is possible to reduce the CPU load from 100% to 50% simply by using a
QOpenGLWidget as plot canvas. With raster we probably never reached 10
frames, so all we know is that the improvement is more than by factor 2.

The rest seems to be related to the grid lines, and updating the tick
labels on the axis.

Updating the tick labels 10 times a second does not make much sense as
nobody can read this. So I would consider this being an issue, that has
to be solved on application side.

But the grid lines are responsible for ~30% of the remaining CPU load, so
let's spend some thoughts on this:

drawing them requires a sequence of QPainter::drawLine calls ( maybe
10-20 ) with a pen width of 1 in Qt::DotLine style. Changing the style to
Qt::SolidLine makes this part of the CPU load disappear - actually the
CPU load becomes the same as when not drawing the grid at all.

So I would guess that the CPU cycles are related to calculating the dots
for each line before forwarding it to some OpenGL call.
Post by Thiago Macieira
If you want faster, redesign with OpenGL in mind.
What does that mean for a task like drawing a dotted line and why do you
consider application code being more effective in finding a fast
implementation for this ?

I would expect the author/maintainer of the OpenGL paint engine being an
expert in how to use OpenGL in the most effective way and the job of this
module should be to keep away those details from the application code.

And what would be the benefit of Qt/Quick for drawing dotted lines ? How
would it be different/superior compared to writing pure OpenGL code - f.e
in QOpenGLWidget::paintGL ?

And why should Denis use Qt at all if he is supposed to break down basic
primitives to pure OpenGL himself ?

Uwe
Jean-Michaël Celerier
2018-09-02 12:48:37 UTC
Permalink
For this kind of work I'd recoment QNanoPainter, it's another Qt paint
engine built on top of modern openGL, very efficient for what you want
(polylines) :
https://github.com/QUItCoding/qnanopainter

Best,
-------
Jean-Michaël Celerier
http://www.jcelerier.name
Post by Uwe Rathmann
Post by Thiago Macieira
You can always just use QPainter on a QPixmap and paint that pixmap on
your QSGPaintedItem. It won't be particularly fast, but it will work and
do what you asked.
After some conversation with Denis: the use case of this thread is a
oscilloscope - drawing a polyline with ~400 points, 10 times a second.
It is possible to reduce the CPU load from 100% to 50% simply by using a
QOpenGLWidget as plot canvas. With raster we probably never reached 10
frames, so all we know is that the improvement is more than by factor 2.
The rest seems to be related to the grid lines, and updating the tick
labels on the axis.
Updating the tick labels 10 times a second does not make much sense as
nobody can read this. So I would consider this being an issue, that has
to be solved on application side.
But the grid lines are responsible for ~30% of the remaining CPU load, so
drawing them requires a sequence of QPainter::drawLine calls ( maybe
10-20 ) with a pen width of 1 in Qt::DotLine style. Changing the style to
Qt::SolidLine makes this part of the CPU load disappear - actually the
CPU load becomes the same as when not drawing the grid at all.
So I would guess that the CPU cycles are related to calculating the dots
for each line before forwarding it to some OpenGL call.
Post by Thiago Macieira
If you want faster, redesign with OpenGL in mind.
What does that mean for a task like drawing a dotted line and why do you
consider application code being more effective in finding a fast
implementation for this ?
I would expect the author/maintainer of the OpenGL paint engine being an
expert in how to use OpenGL in the most effective way and the job of this
module should be to keep away those details from the application code.
And what would be the benefit of Qt/Quick for drawing dotted lines ? How
would it be different/superior compared to writing pure OpenGL code - f.e
in QOpenGLWidget::paintGL ?
And why should Denis use Qt at all if he is supposed to break down basic
primitives to pure OpenGL himself ?
Uwe
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Uwe Rathmann
2018-09-02 13:05:57 UTC
Permalink
For this kind of work I'd recoment QNanoPainter, ...
I also gave this hint to Denis - without having any experience with it
myself. When I have more time I will check if its is possible for Qwt to
benefit from this backend.

Do you have any numbers, when comparing the specific problem of drawing
dotted lines ?

Thiago argues, that a QPainter based render engine results in performance
bottlenecks. But if it is possible to have significantly better results
with QNanoPainter then there is no conceptual problem and Qt development
could improve the situation by working on the code of the OpenGL paint
engine.

Uwe
Thiago Macieira
2018-09-02 18:01:31 UTC
Permalink
Post by Uwe Rathmann
Thiago argues, that a QPainter based render engine results in performance
bottlenecks. But if it is possible to have significantly better results
with QNanoPainter then there is no conceptual problem and Qt development
could improve the situation by working on the code of the OpenGL paint
engine.
There is a conceptual problem. You're never going to match the performance of
something designed with retained mode and OpenGL in mind if every redraw every
frame from scratch. In an imperative-mode paint engine, every time
paintEvent() happens, the world restarts. Every frame can be completely
different from the previous one. So the code that maps this back to OpenGL has
to do a lot of state management behind the scenes to avoid recreating
everything from scratch.

You can get a lot of things done, but there's a limit. The complexity can
become unmanageable at some point. Either way, there's a ceiling of
performance.

Back in 2010, when Qt developers began talking to Clutter developers due to
the MeeGo project, Clutter developers told us how they accomplished COGL
(Clutter On OpenGL). Clutter had (has?) a huge state-management and caching
engine, trying to reorder your imperative painting events so that the amount
of OpenGL work was reduced, with fewer state transitions. It worked pretty
well and that's what the Qt 4.6 through 4.8 OpenGL Paint Engine tried to do
too. I don't know qnanopainter, but there's a good change it's doing that too.

Clutter achieved pretty good results, but mind you that developers who worked
on it worked for Intel (Openedhand had been acquired recently) and only
optimised for the Intel desktop-class GPU, for which the driver source was
open, allowing the developers to understand what cost more. Nokia developers,
on the other hand, were fighting against the PowerVR mobile-class GPU with the
Imagination closed-source drivers, running on seriously underpowered ARMv6
CPUs. On one particular Nokia device, the glSwapBuffers() call itself was
taking 13 ms, or 78% of the time budget for each frame.

The solution to do CPU work to buffer GPU commands to reorder them and cache
states simply did not get us the performance we needed. By the end of 2010, we
had already noticed this and we had two developers (Gunnar and Kim) working on
figuring out how to write proper code to use the GPU the way the GPU is meant
to be used. This event is what I am calling the end of the OpenGL paint engine
experiment and the birth of the scene graph.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Simon Hausmann
2018-09-03 14:38:51 UTC
Permalink
Post by Thiago Macieira
Post by Uwe Rathmann
Thiago argues, that a QPainter based render engine results in performance
bottlenecks. But if it is possible to have significantly better results
with QNanoPainter then there is no conceptual problem and Qt development
could improve the situation by working on the code of the OpenGL paint
engine.
There is a conceptual problem. You're never going to match the performance of
something designed with retained mode and OpenGL in mind if every redraw every
frame from scratch. In an imperative-mode paint engine, every time
paintEvent() happens, the world restarts. Every frame can be completely
different from the previous one. So the code that maps this back to OpenGL has
to do a lot of state management behind the scenes to avoid recreating
everything from scratch.
You can get a lot of things done, but there's a limit. The complexity can
become unmanageable at some point. Either way, there's a ceiling of
performance.
Back in 2010, when Qt developers began talking to Clutter developers due to
the MeeGo project, Clutter developers told us how they accomplished COGL
(Clutter On OpenGL). Clutter had (has?) a huge state-management and caching
engine, trying to reorder your imperative painting events so that the amount
of OpenGL work was reduced, with fewer state transitions. It worked pretty
well and that's what the Qt 4.6 through 4.8 OpenGL Paint Engine tried to do
too. I don't know qnanopainter, but there's a good change it's doing that too.
Clutter achieved pretty good results, but mind you that developers who worked
on it worked for Intel (Openedhand had been acquired recently) and only
optimised for the Intel desktop-class GPU, for which the driver source was
open, allowing the developers to understand what cost more. Nokia developers,
on the other hand, were fighting against the PowerVR mobile-class GPU with the
Imagination closed-source drivers, running on seriously underpowered ARMv6
CPUs. On one particular Nokia device, the glSwapBuffers() call itself was
taking 13 ms, or 78% of the time budget for each frame.
The solution to do CPU work to buffer GPU commands to reorder them and cache
states simply did not get us the performance we needed. By the end of 2010, we
had already noticed this and we had two developers (Gunnar and Kim) working on
figuring out how to write proper code to use the GPU the way the GPU is meant
to be used. This event is what I am calling the end of the OpenGL paint engine
experiment and the birth of the scene graph.
In addition to what Thiago beautifully summarized, there's one other
difference between QNanoPainter and QPainter: The former is a new API
that can limit itself to features that work well with OpenGL, while with
QPainter the range of different features and expected behavior is
bigger. So the GL paint-engine has to do certain things in a certain way
to maintain compatibility with the way QPainter is expected to behave
when it is used on a raster surface. This may come at the expense of
performance.


I'm sure this isn't quite news, but together with Thiago's statements I
think this summarizes that while it may be possible to squeeze out
perhaps a little more with the GL paint engine, it's not necessarily a
good overall investment of time when the scene graph provides a better
opportunity to get closer to the theoretical maximum of performance - by
design.


Simon
Uwe Rathmann
2018-09-03 16:19:31 UTC
Permalink
... it's not necessarily a
good overall investment of time when the scene graph provides a better
opportunity to get closer to the theoretical maximum of performance - by
design.
In German we have the phrase: "Besser ein Spatz in der Hand als eine
Taube auf dem Dach".

For many situations I would already be very happy with having back the
performance of what I can achieve with Qt4/X11. And IMHO the minimally
invasive option would be QWidget/QPixmap ( not QOpenGLWidget ) being a
paint device, that runs on a OpenGL paint engine.

But if you even decide to migrate Qt/Widgets running on top of the scene
graph - that would be fantastic news.

Almost everything is better than to continue forever with a graphic
pipeline, that is not even competitive with the one that had been sorted
out in 2010.

Uwe
Thiago Macieira
2018-09-03 19:39:22 UTC
Permalink
Post by Uwe Rathmann
Almost everything is better than to continue forever with a graphic
pipeline, that is not even competitive with the one that had been sorted
out in 2010.
Your criteria for "competitive" are different than the maintainers'. You're
not including the pathological cases where the X11 graphics system didn't
perform as well and required the raster engine to kick in. And you're not
including the need to produce the exact same result in all platforms.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-09-04 07:03:10 UTC
Permalink
Post by Thiago Macieira
Your criteria for "competitive" are different than the maintainers'.
I was referring to the work of Gunnar and Kim, but comparing X11 with
Raster and the quality of the implementation of the Raster paint engine
are interesting topics as well.
Post by Thiago Macieira
You're not including the pathological cases where the X11 graphics
system didn't perform as well and required the raster engine to kick in.
As being the maintainer of a cross platform library build on top of
QPainter I have some experience in this area:

when it comes to vector graphics X11 just rocks. Performance is much
better and I never had all these bugs of Raster coming and going with
every version. Actually my code is full of #ifdefs with enabling/
disabling workarounds for specific bugs in specific Qt versions.

F.e:

- https://bugreports.qt.io/browse/QTBUG-42398
- https://bugreports.qt.io/browse/QTBUG-70101

The situation for doing raster operations is the opposite. Actually I
have code that fills QImages with gradients before drawing them to a
QPixmap to get around X11 issues.

--

Concerning the performance: the use case of technical plots is often
about drawing curves ( unfilled painter paths, with a simple pen ) of
many points.

I once played with doing my own rasterization ( setting the pixels
manually to a QImage ) by implementing a few algos you need:

- https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
- https://en.wikipedia.org/wiki/De_Casteljau%27s_algorithm
- https://en.wikipedia.org/wiki/Xiaolin_Wu%27s_line_algorithm

Unfortunately I don't have the code anymore and of course it is not fair
to compare a feature rich API like QPainter with something that is
optimized for a specific use case, but: AFAIR the improvement was
significant.
Post by Thiago Macieira
And you're not including the need to produce the exact same result in
all platforms.
This is also a quite interesting topic, as the incompatibilities between
the different paint engines is in fact a nasty problem.

F.e. drawing a simple line with a FlatCap: for some reason it is
specified ( https://doc.qt.io/qt-5/qpen.html#cap-style ) not to draw the
"endpoint". Actually this not what the X11 paint engine does - never did
- and you have a mismatch with Raster over all Qt4 releases.

The OpenGL paint engine shifts everything by one pixel to the left
compared to Raster. I thought I added a bug report for this very
fundamental problem a couple of years ago, but I can't find it.
Anyway, I'm not the only one:

- https://bugreports.qt.io/browse/QTBUG-27500

Please note, that the final comment of this report indicates, that the
incompatibility between raster and opengl won't be fixed, because X11 is
no longer supported !

Uwe
Philippe
2018-09-02 17:57:27 UTC
Permalink
For this kind of work I'd recoment QNanoPainter, it's another Qt paint engine built on top of modern openGL,
https://github.com/QUItCoding/qnanopainter
Interesting, the demo works out of the box and is impressive.

Philippe
Thiago Macieira
2018-09-02 17:45:37 UTC
Permalink
Post by Uwe Rathmann
And why should Denis use Qt at all if he is supposed to break down basic
primitives to pure OpenGL himself ?
He uses Qt for everything else, like mapping windows from the windowing
system, input event management, etc. Also, note I said "design with OpenGL in
mind", not "design with OpenGL". So what needs changing is the way of
thinking, not necessarily the code itself. Using OpenGL and repainting
everything from scratch with a lot of CPU calculation is not going to help.

The point is that if you need the performance of graphics, you need to use the
GPU the way the GPU is designed. Reduce your CPU work and use more retained
settings across frames.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-09-02 14:18:10 UTC
Permalink
Post by Thiago Macieira
Post by Uwe Rathmann
From my experience with the QSkinny project I'm tempted to say that it
would even be possible to implement the Qt/Widgets API on top of
Qt/Quick core.
So long as you ditch the paint event for most of the classes, leaving
the QQuickPaintedItem (or whatever it's called) only for the cases where
it's truly needed.
When implementing widgets ( inside of Qt or 3rd party widgets like in Qwt
) it is mostly a matter of handling resize and paint events.

The corresponding calls for Qt/Quick are QQuickItem::geometryChanged and
QQuickItem::updatePaintNode().

So when trying to migrate widgets into being QQuickItems you would have
to send QResizeEvents inside of geometryChanged and QPaintEvents inside
of updatePaintNode.

All of these "widgets" could have an FBO ( or QPixmap ) inside and
creating a QPainter on a them would result in drawing to this one. Then
it would be possible to create a scene graph node from it.

Of course I'm heavily oversimplifying, but this way you would at least
get something running in a reasonable amount of time - even if this would
downgrade the scene graph into being a texture cache.

But it would be a starting point for migrating the implementation of
updatePaintNode widget by widget.

--

But does it make any sense to spend time on this:

In the context of Qt 5.0, where the strategy was to replace Widgets by
Quick Controls 1 - probably not.

But QC1 has become a failed technology and QC2 is not targeting the
desktop anymore. So all what Qt has to offer today for the desktop is
good old Widgets - running on a graphic stack, that is not competitive
anymore.

So in the retrospective IMHO the wrong decision had been made.
And for the future - no idea, is there already a strategy how to satisfy
desktop users with Qt 6 ?

Uwe
Uwe Rathmann
2018-08-30 13:52:15 UTC
Permalink
Post by Denis Shienkov
Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and
QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50%
(instead of previous 100%).
A small correction for others reading this: trunk is Qwt 6.3. The main
difference to the code you find in the 6.2 branch is exactly about the
OpenGL canvases, where I need more time to find workarounds for the
incompatibilities of the OpenGL paint engines.

I also forgot to mention that Qwt from trunk also has the option
QwtPlotCanvas::OpenGLBuffer. In this mode rendering is also done hardware
accelerated - using the OpenGL paint engine to an offscreen FBO. Then the
FBO gets copied to a QImage being rendered to a normal QWidget.

This combination should also work with EGLFS. But of course copying from
GPU to CPU and back for each frame might kill your performance
requirements.

Please let me know what you can achieve with this combination ?

Uwe
Vlad Stelmahovsky
2018-08-29 15:56:08 UTC
Permalink
have you tried QOpenGlWidget ?

otherwise you dont have other options: plain QWidget's does not HW
accelerated

or, you can extend QtCharts to be more QtQuicker and more featured.
everyone will be happy :)
Post by Denis Shienkov
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the working
'eglfs' and 'linuxfb'  backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to use a
real-time plotting with the Qwt library (using the Qt Quick is not an
option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as
with the 'eglfs' and as with 'linuxfb' backends. It is not an
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU
loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's
image to enable the X11 'xcb' support?
BR,
Denis
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Denis Shienkov
2018-08-29 17:49:20 UTC
Permalink
Hi,
Post by Vlad Stelmahovsky
have you tried QOpenGlWidget ?
It does not work together (can't be mixed) with an usual QtWidgets using
the 'eglfs' backend.
Post by Vlad Stelmahovsky
QtCharts to be more QtQuicker and more featured
As I see from the QtCharts sources, it also renders via QGraphicsScene
&& QGraphicsWidget even in QtQuick.
Post by Vlad Stelmahovsky
have you tried QOpenGlWidget ?
otherwise you dont have other options: plain QWidget's does not HW
accelerated
or, you can extend QtCharts to be more QtQuicker and more featured.
everyone will be happy :)
Post by Denis Shienkov
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the working
'eglfs' and 'linuxfb'  backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to use
a real-time plotting with the Qwt library (using the Qt Quick is not
an option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU loading
as with the 'eglfs' and as with 'linuxfb' backends. It is not an
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU
loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's
image to enable the X11 'xcb' support?
BR,
Denis
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Arno Rehn
2018-09-04 09:00:09 UTC
Permalink
Hi everyone,

because I've hit the same issues on an embedded platform with eglfs (was
the Raspberry Pi, not iMX6), I've thrown together some classes for
native QtQuick/OpenGL plotting. Performance on the Raspberry Pi is
excellent from my experience (5% CPU usage on the R-Pi with a
continuously updated plot).

Repository: https://gitlab.com/qtquickplot/qtquickplot
Blog entry with some explanations:
http://www.arnorehn.de/blog/2014/12/quickplot-a-collection-of-native-qtquick-plot-items/

Regards,
Post by Denis Shienkov
Hi,
Post by Vlad Stelmahovsky
have you tried QOpenGlWidget ?
It does not work together (can't be mixed) with an usual QtWidgets using
the 'eglfs' backend.
Post by Vlad Stelmahovsky
QtCharts to be more QtQuicker and more featured
As I see from the QtCharts sources, it also renders via QGraphicsScene
&& QGraphicsWidget even in QtQuick.
Post by Vlad Stelmahovsky
have you tried QOpenGlWidget ?
otherwise you dont have other options: plain QWidget's does not HW
accelerated
or, you can extend QtCharts to be more QtQuicker and more featured.
everyone will be happy :)
Post by Denis Shienkov
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the working
'eglfs' and 'linuxfb'  backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to use
a real-time plotting with the Qwt library (using the Qt Quick is not
an option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU loading
as with the 'eglfs' and as with 'linuxfb' backends. It is not an
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU
loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's
image to enable the X11 'xcb' support?
BR,
Denis
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
***@menlosystems.com
www.menlosystems.com

Menlo Systems GmbH
Am Klopferspitz 19a, 82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
Denis Shienkov
2018-09-04 09:21:29 UTC
Permalink
Hi, guys.

Many thanks for your help.

But a problem is that I already have a QtWidgets-based application. And
porting to the QtQuick
+ hacking with custom QuickPlots (or other stuff) will take a lot of time.

Uwe,
what if I try to back-port my application from Qt5 to Qt4 with X11
support (on iMX6).
As I understand, then I do not need to specify the OpenGL Widgets with
Qt4. Is it?
Is it will help? Or do I need to use the QtQuick anyway?

Denis
Post by Arno Rehn
Hi everyone,
because I've hit the same issues on an embedded platform with eglfs
(was the Raspberry Pi, not iMX6), I've thrown together some classes
for native QtQuick/OpenGL plotting. Performance on the Raspberry Pi is
excellent from my experience (5% CPU usage on the R-Pi with a
continuously updated plot).
Repository: https://gitlab.com/qtquickplot/qtquickplot
http://www.arnorehn.de/blog/2014/12/quickplot-a-collection-of-native-qtquick-plot-items/
Regards,
Hi,
 > have you tried QOpenGlWidget ?
It does not work together (can't be mixed) with an usual QtWidgets
using the 'eglfs' backend.
 > QtCharts to be more QtQuicker and more featured
As I see from the QtCharts sources, it also renders via
QGraphicsScene && QGraphicsWidget even in QtQuick.
Post by Vlad Stelmahovsky
have you tried QOpenGlWidget ?
otherwise you dont have other options: plain QWidget's does not HW
accelerated
or, you can extend QtCharts to be more QtQuicker and more featured.
everyone will be happy :)
Post by Denis Shienkov
Hi all.
I have an Apalis iMX6 board with the Yocto's image with the working
'eglfs' and 'linuxfb'  backends (without of X11 support).
I need to create a 'pure' QtWidgets application, where I need to
use a real-time plotting with the Qwt library (using the Qt Quick
is not an option, as there the QtCharts is not ready for usage) .
But, I'm sadly surprised that a 2D painting takes ~100% CPU loading
as with the 'eglfs' and as with 'linuxfb' backends. It is not an
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5%
CPU loading.
Is any workarounds for this? Maybe I need to re-build the Yocto's
image to enable the X11 'xcb' support?
BR,
Denis
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Uwe Rathmann
2018-09-04 10:14:43 UTC
Permalink
Post by Denis Shienkov
Uwe,
what if I try to back-port my application from Qt5 to Qt4 with X11
support (on iMX6).
This is what I would try first in a situation like yours. Don't forget to
set the graphic system to "native" - the default since 4.8 is raster.
Post by Denis Shienkov
As I understand, then I do not need to specify the OpenGL Widgets with
Qt4.
Right and you might even see a lower CPU load depending on what happens
in the various paint engines before calling the native libs.
Post by Denis Shienkov
Is it will help? Or do I need to use the QtQuick anyway?
When looking at Arnos blog it looks like he has a stable coordinate
system, where he only updates the curves with each frame ( please correct
me if I'm wrong ). I would recommend to do this for your application too
- having different tick labels with each frame will be an issue with all
backends.

In this situation you would have a positive effect for drawing the
decoration of the plot canvas ( background/grid/... ) with using the
scene graph. As the axes are different widgets with Qwt, they would not
been updated with each frame - so the performance for rendering axes and
tick labels does not matter here.

But you could do something similar with QPainter by drawing these parts
to a QPixmap once and reusing it for each frame. If you are interested -
contact me at one of the Qwt support channels.

For drawing the curves itself I wouldn't see many benefits from using Qt/
Quick as they do change with each frame. You might even have unwanted
effects as you might need more memory - anyone who knows better, please
correct me.

IMHO I would expect, that you could get the optimal performance by doing
native OpenGL with QOpenGLWidget::paintGL. But drawing a polyline of 400
points with 10fps should also be no problem on an iMX6 with QPainter/X11.

But also note that Qt/Quick is much more than the scene graph. It is a
technology, that includes a JavaScript experience and you always have a
run time environment processing this code: if this matters is something
only you can decide.

Uwe
Denis Shienkov
2018-09-04 11:38:47 UTC
Permalink
Uwe,
Don't forget to set the graphic system to "native" - the default
since 4.8 is raster

How I can do it for Qt4?  Do you mean, I need to specify an appropriate
'-platform' option
before starting of my application on Qt4?

PS: Many thanks for your help. Of course I will create an additional
questions
in 'Qwt' topic of qtcentre forum when the time comes. :)

Denis
Uwe Rathmann
2018-09-04 12:31:26 UTC
Permalink
How I can do it for Qt4?  Do you mean, I need to specify an appropriate
'-platform' option before starting of my application on Qt4?
https://doc.qt.io/archives/qt-4.8/qapplication.html#setGraphicsSystem

You can even run opengl as backend for all widgets this way, what might
be an option for non X11 platforms. I should pay more attention to this
option for future Qwt releases.

The vertical lines of the rubberbands are clipped away because of the 1
pixel left shift of the OpenGL paint engine, but the ticks of the axes
and the grid lines of the canvas are correctly aligned - in opposite to
the Qt5/QOpenGLWidget combination.

But please allow me to repeat the hint about trying the
QwtPlotCanvas::OpenGLBuffer option. It introduces some overhead, but at
least avoids doing the rasterization of the vector data with the CPU. It
works with Qt5 ( even with EGLFS ) without having to fiddle around with
QOpenGLWidget.

All you need to do is to add one line to your code:

plot->canvas()->setPaintAttribute( QwtPlotCanvas::OpenGLBuffer );

Uwe

PS: this starts to become too offtopic for this list
Thiago Macieira
2018-09-04 14:44:24 UTC
Permalink
Post by Uwe Rathmann
Post by Denis Shienkov
Uwe,
what if I try to back-port my application from Qt5 to Qt4 with X11
support (on iMX6).
This is what I would try first in a situation like yours. Don't forget to
set the graphic system to "native" - the default since 4.8 is raster.
Please note Qt 4 is out of support, is not receiving security updates and has
known security problems. It would be irresponsible to use it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Cristian Adam
2018-09-04 15:16:34 UTC
Permalink
Post by Thiago Macieira
Please note Qt 4 is out of support, is not receiving security updates and has
known security problems. It would be irresponsible to use it.
Have a look at http://www.copperspice.com/, which is a Qt 4 fork, and it's
being
constantly updated. (C++14, UTF-8 for strings, CMake build system etc.)

Cheers,
Cristian.
Thiago Macieira
2018-09-04 15:21:54 UTC
Permalink
Post by Cristian Adam
Post by Thiago Macieira
Please note Qt 4 is out of support, is not receiving security updates and has
known security problems. It would be irresponsible to use it.
Have a look at http://www.copperspice.com/, which is a Qt 4 fork, and it's
being
constantly updated. (C++14, UTF-8 for strings, CMake build system etc.)
That's not an update, that's a fork. The API is different and you need to
adapt your code to them.

And are you sure they're applying the security fixes? You may want to take a
look at their Git log for the XML parser and image handlers, those are where
we get our security issues reported on.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Martin Koller
2018-09-04 18:51:38 UTC
Permalink
Post by Uwe Rathmann
Post by Denis Shienkov
Uwe,
what if I try to back-port my application from Qt5 to Qt4 with X11
support (on iMX6).
This is what I would try first in a situation like yours. Don't forget to
set the graphic system to "native" - the default since 4.8 is raster.
https://codereview.qt-project.org/#/c/181609/

added the native X11 graphicssystem support from Qt4 to Qt5
--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Uwe Rathmann
2018-09-05 05:58:44 UTC
Permalink
Post by Martin Koller
added the native X11 graphicssystem support from Qt4 to Qt5
Very cool.

Andrew told me that there were 2 concurrent attempts to revive X11 as the
situation for running widget applications on remote desktops is simply
not good, when using Raster. But I never realized, that finally something
went into the Qt code base.

What needs to be done to make it become effective ?

Uwe
Denis Shienkov
2018-09-05 08:33:46 UTC
Permalink
Hi,
Post by Martin Koller
added the native X11 graphicssystem support from Qt4 to Qt5
According to that commit (and next depends commits), seems this porting is
not completed yet to Qt5.
So, it is interest to know: can we use it in current time, and since what
of Qt version? Is it work at all as in Qt4?

And, as Uwe said: how we can enable this feature, what needs to do?

Denis
Post by Martin Koller
Post by Martin Koller
added the native X11 graphicssystem support from Qt4 to Qt5
Very cool.
Andrew told me that there were 2 concurrent attempts to revive X11 as the
situation for running widget applications on remote desktops is simply
not good, when using Raster. But I never realized, that finally something
went into the Qt code base.
What needs to be done to make it become effective ?
Uwe
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Uwe Rathmann
2018-09-05 09:29:15 UTC
Permalink
Post by Uwe Rathmann
What needs to be done to make it become effective ?
export QT_XCB_NATIVE_PAINTING=1
I did a quick check with using QPainter on a QPixmap and indeed it runs
the X11 paint engine. Using Qwt with a current Qt version seems to run
the same ways as with Qt4/X11 without any problems.

So this is great news - at least for me, others might be aware of this
option for a longer time.

I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I
understand, that reverting a decision is not stuff for big announcements,
but for such an important improvement: has it been communicated at least
somewhere ?

It also raises questions about the status of the X11 paint engine.
Several bugs have been closed because of not fixing the X11 paint engine
anymore.

Does it make sense to write bug reports, when it behaves not according to
the specs - or when it differs from what the raster paint engine does ?

Uwe
Denis Shienkov
2018-09-05 10:04:39 UTC
Permalink
Post by Uwe Rathmann
Using Qwt with a current Qt version seems to run
the same ways as with Qt4/X11 without any problems.

Uwe, wow :) What Qt5 version are you use?

Denis
Post by Uwe Rathmann
Post by Uwe Rathmann
What needs to be done to make it become effective ?
export QT_XCB_NATIVE_PAINTING=1
I did a quick check with using QPainter on a QPixmap and indeed it runs
the X11 paint engine. Using Qwt with a current Qt version seems to run
the same ways as with Qt4/X11 without any problems.
So this is great news - at least for me, others might be aware of this
option for a longer time.
I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I
understand, that reverting a decision is not stuff for big announcements,
but for such an important improvement: has it been communicated at least
somewhere ?
It also raises questions about the status of the X11 paint engine.
Several bugs have been closed because of not fixing the X11 paint engine
anymore.
Does it make sense to write bug reports, when it behaves not according to
the specs - or when it differs from what the raster paint engine does ?
Uwe
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Uwe Rathmann
2018-09-05 18:50:13 UTC
Permalink
Post by Denis Shienkov
Uwe, wow :) What Qt5 version are you use?
Seems to work with Qt5 >= 5.10.

Uwe
Thiago Macieira
2018-09-05 16:55:41 UTC
Permalink
Post by Uwe Rathmann
I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I
understand, that reverting a decision is not stuff for big announcements,
but for such an important improvement: has it been communicated at least
somewhere ?
Because it's not an important improvement for most people. Your case and
Denis's, as seen in this thread, are very specific. Most people are fine with
the raster engine.
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint engine.
Several bugs have been closed because of not fixing the X11 paint engine
anymore.
This being the reason why the X11 engine is not good for everyone.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
André Pönitz
2018-09-05 06:26:27 UTC
Permalink
Post by Thiago Macieira
Post by Uwe Rathmann
I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I
understand, that reverting a decision is not stuff for big announcements,
but for such an important improvement: has it been communicated at least
somewhere ?
Because it's not an important improvement for most people. Your case and
Denis's, as seen in this thread, are very specific. Most people are
fine with the raster engine.
If "Most people do not $X" were a sensible line of reasoning in the
Qt context we could remove pretty much every feature in Qt one-by-one.

Most people are *not* using Linux.
Most people are *not* using Android.
Most people are *not* using iOS.
Most people are *not* using Window 7.
Most people are *not* using Window 10.
...

Most people are *not* using Webkit.
Most people are *not* using WebEngine.
Most people are *not* using print support.
Most people are *not* using 3D
...

Most people are *not* using CBOR
...

See the pattern?

Andre'
Thiago Macieira
2018-09-05 21:00:15 UTC
Permalink
Post by André Pönitz
Post by Thiago Macieira
Because it's not an important improvement for most people. Your case and
Denis's, as seen in this thread, are very specific. Most people are
fine with the raster engine.
If "Most people do not $X" were a sensible line of reasoning in the
Qt context we could remove pretty much every feature in Qt one-by-one.
You're completely right. What I meant to say is that the audience is very
restricted, which is why it wasn't announced widely. From what I gather, it's
still got a few rough edges, so it wouldn't make sense to announce yet either.

As soon as it's usable, it should appear in the ChangeLog.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-09-05 19:57:39 UTC
Permalink
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint engine.
Several bugs have been closed because of not fixing the X11 paint
engine anymore.
This being the reason why the X11 engine is not good for everyone.
O.k. - but that does not answer my question regarding the status of the
code ?

Uwe
Thiago Macieira
2018-09-05 21:00:48 UTC
Permalink
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint engine.
Several bugs have been closed because of not fixing the X11 paint
engine anymore.
This being the reason why the X11 engine is not good for everyone.
O.k. - but that does not answer my question regarding the status of the
code ?
I'm guessing it's
"Experimental, use at your own risk, please report bugs, don't expect quick
turnaround time."
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Denis Shienkov
2018-09-10 10:59:48 UTC
Permalink
Hi guys,

does this mean (for Qt 5.11.1 config output):

X11:
Using system-provided XCB libraries .. no
EGL on X11 ........................... yes
Xinput2 .............................. no
XCB XKB .............................. yes
XLib ................................. yes
XCB render ........................... yes
XCB GLX .............................. yes
XCB Xlib ............................. yes
Using system-provided xkbcommon ...... no
Native painting (experimental) ....... no

that this required *native painting* feature is not configured
successfully?

Denis
Post by Thiago Macieira
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint engine.
Several bugs have been closed because of not fixing the X11 paint
engine anymore.
This being the reason why the X11 engine is not good for everyone.
O.k. - but that does not answer my question regarding the status of the
code ?
I'm guessing it's
"Experimental, use at your own risk, please report bugs, don't expect quick
turnaround time."
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Dominik Holland
2018-09-10 11:03:40 UTC
Permalink
Hi,

try to pass --feature-xcb-native-painting to configure. That should
enable it or atleast explain what's missing.

Dominik
Post by Denis Shienkov
Hi guys,
    Using system-provided XCB libraries .. no
    EGL on X11 ........................... yes
    Xinput2 .............................. no
    XCB XKB .............................. yes
    XLib ................................. yes
    XCB render ........................... yes
    XCB GLX .............................. yes
    XCB Xlib ............................. yes
    Using system-provided xkbcommon ...... no
    Native painting (experimental) ....... no
that this required *native painting* feature is not configured
successfully?
Denis
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint
engine.
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
Several bugs have been closed because of not fixing the X11 paint
engine anymore.
This being the reason why the X11 engine is not good for everyone.
O.k. - but that does not answer my question regarding the status
of the
Post by Uwe Rathmann
code ?
I'm guessing it's
"Experimental, use at your own risk, please report bugs, don't expect quick
turnaround time."
--
Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com>
  Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Denis Shienkov
2018-09-10 11:29:03 UTC
Permalink
Post by Dominik Holland
--feature-xcb-native-painting
I have added this to my configure script, but it has not any effects, it
does not show an additional errors at configure time.
Besides, I have not found this 'feature-xcb-native-painting' pattern in qt5
sources:

grep -rn . -e 'feature-xcb-native-painting'

Denis


пМ, 10 сеМт. 2018 г. в 14:04, Dominik Holland <
Post by Dominik Holland
Hi,
try to pass --feature-xcb-native-painting to configure. That should
enable it or atleast explain what's missing.
Dominik
Post by Denis Shienkov
Hi guys,
Using system-provided XCB libraries .. no
EGL on X11 ........................... yes
Xinput2 .............................. no
XCB XKB .............................. yes
XLib ................................. yes
XCB render ........................... yes
XCB GLX .............................. yes
XCB Xlib ............................. yes
Using system-provided xkbcommon ...... no
Native painting (experimental) ....... no
that this required *native painting* feature is not configured
successfully?
Denis
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint
engine.
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
Several bugs have been closed because of not fixing the X11
paint
Post by Denis Shienkov
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
engine anymore.
This being the reason why the X11 engine is not good for
everyone.
Post by Denis Shienkov
Post by Uwe Rathmann
O.k. - but that does not answer my question regarding the status
of the
Post by Uwe Rathmann
code ?
I'm guessing it's
"Experimental, use at your own risk, please report bugs, don't expect quick
turnaround time."
--
Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com>
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Denis Shienkov
2018-09-10 11:36:33 UTC
Permalink
I even have added this:

-xcb-native-painting \

as described in qtbase/dist/changes-5.10.0 , but it has not effect too.. no
any errors printed out.
Post by Denis Shienkov
Post by Dominik Holland
--feature-xcb-native-painting
I have added this to my configure script, but it has not any effects, it
does not show an additional errors at configure time.
Besides, I have not found this 'feature-xcb-native-painting' pattern in
grep -rn . -e 'feature-xcb-native-painting'
Denis
пМ, 10 сеМт. 2018 г. в 14:04, Dominik Holland <
Post by Dominik Holland
Hi,
try to pass --feature-xcb-native-painting to configure. That should
enable it or atleast explain what's missing.
Dominik
Post by Denis Shienkov
Hi guys,
Using system-provided XCB libraries .. no
EGL on X11 ........................... yes
Xinput2 .............................. no
XCB XKB .............................. yes
XLib ................................. yes
XCB render ........................... yes
XCB GLX .............................. yes
XCB Xlib ............................. yes
Using system-provided xkbcommon ...... no
Native painting (experimental) ....... no
that this required *native painting* feature is not configured
successfully?
Denis
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint
engine.
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
Several bugs have been closed because of not fixing the X11
paint
Post by Denis Shienkov
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
engine anymore.
This being the reason why the X11 engine is not good for
everyone.
Post by Denis Shienkov
Post by Uwe Rathmann
O.k. - but that does not answer my question regarding the status
of the
Post by Uwe Rathmann
code ?
I'm guessing it's
"Experimental, use at your own risk, please report bugs, don't expect quick
turnaround time."
--
Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com>
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Denis Shienkov
2018-09-10 13:30:32 UTC
Permalink
Ok, I have compiled my Qt 5.11.1 with native XCB painting support, using
following configure options:

-system-freetype \
-fontconfig \
-xcb-native-painting \

but I don't see any differences using the QT_XCB_NATIVE_PAINTING=1 or
without of it.
The CPU usage still is a big ~71% in both cases.

How I can know that the QT_XCB_NATIVE_PAINTING are applied?

Denis
Post by Denis Shienkov
-xcb-native-painting \
as described in qtbase/dist/changes-5.10.0 , but it has not effect too..
no any errors printed out.
Post by Denis Shienkov
Post by Dominik Holland
--feature-xcb-native-painting
I have added this to my configure script, but it has not any effects, it
does not show an additional errors at configure time.
Besides, I have not found this 'feature-xcb-native-painting' pattern in
grep -rn . -e 'feature-xcb-native-painting'
Denis
пМ, 10 сеМт. 2018 г. в 14:04, Dominik Holland <
Post by Dominik Holland
Hi,
try to pass --feature-xcb-native-painting to configure. That should
enable it or atleast explain what's missing.
Dominik
Post by Denis Shienkov
Hi guys,
Using system-provided XCB libraries .. no
EGL on X11 ........................... yes
Xinput2 .............................. no
XCB XKB .............................. yes
XLib ................................. yes
XCB render ........................... yes
XCB GLX .............................. yes
XCB Xlib ............................. yes
Using system-provided xkbcommon ...... no
Native painting (experimental) ....... no
that this required *native painting* feature is not configured
successfully?
Denis
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
It also raises questions about the status of the X11 paint
engine.
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
Several bugs have been closed because of not fixing the X11
paint
Post by Denis Shienkov
Post by Uwe Rathmann
Post by Thiago Macieira
Post by Uwe Rathmann
engine anymore.
This being the reason why the X11 engine is not good for
everyone.
Post by Denis Shienkov
Post by Uwe Rathmann
O.k. - but that does not answer my question regarding the status
of the
Post by Uwe Rathmann
code ?
I'm guessing it's
"Experimental, use at your own risk, please report bugs, don't expect quick
turnaround time."
--
Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development
Uwe Rathmann
2018-09-10 14:00:41 UTC
Permalink
Post by Denis Shienkov
but I don't see any differences using the QT_XCB_NATIVE_PAINTING=1 or
without of it.
The CPU usage still is a big ~71% in both cases.
As long as you are updating the tick labels 10 times a second I would
expect, that you have a CPU load, that is unrelated to your graphic
pipeline.

As said several times before: try to make your coordinate system more
stable or at least reduce how often you are shifting.

( But this is offtopic for this mailing list )
Post by Denis Shienkov
How I can know that the QT_XCB_NATIVE_PAINTING are applied?
painter->paintEngine()->type() should return 0, when the corresponding
paint device is a QPixmap or QWidget ( not QImage ).

Uwe

Loading...