Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Mon, 10 Sep 2018 16:30:32 +0300, Denis Shienkov wrote:

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

> 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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


пн, 10 сент. 2018 г. в 14:36, Denis Shienkov :

> 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.
>
>
>
> пн, 10 сент. 2018 г. в 14:29, Denis Shienkov :
>
>> > --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 <
>> dominik.holl...@pelagicore.com>:
>>
>>> Hi,
>>>
>>> try to pass --feature-xcb-native-painting to configure. That should
>>> enable it or atleast explain what's missing.
>>>
>>> Dominik
>>>
>>>
>>> Am 09/10/2018 um 12:59 PM schrieb Denis Shienkov:
>>> > 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
>>> >
>>> > чт, 6 сент. 2018 г. в 0:02, Thiago Macieira >> > >:
>>> >
>>> > On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
>>> > > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
>>> > > >> 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
>>> > Development@qt-project.org 
>>> > http://lists.qt-project.org/mailman/listinfo/development
>>> >
>>> >
>>> >
>>> > ___
>>> > Development mailing list
>>> > Development@qt-project.org
>>> > http://lists.qt-project.org/mailman/listinfo/development
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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.



пн, 10 сент. 2018 г. в 14:29, Denis Shienkov :

> > --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 <
> dominik.holl...@pelagicore.com>:
>
>> Hi,
>>
>> try to pass --feature-xcb-native-painting to configure. That should
>> enable it or atleast explain what's missing.
>>
>> Dominik
>>
>>
>> Am 09/10/2018 um 12:59 PM schrieb Denis Shienkov:
>> > 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
>> >
>> > чт, 6 сент. 2018 г. в 0:02, Thiago Macieira > > >:
>> >
>> > On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
>> > > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
>> > > >> 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
>> > Development@qt-project.org 
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>> >
>> >
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/development
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

> --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 <
dominik.holl...@pelagicore.com>:

> Hi,
>
> try to pass --feature-xcb-native-painting to configure. That should
> enable it or atleast explain what's missing.
>
> Dominik
>
>
> Am 09/10/2018 um 12:59 PM schrieb Denis Shienkov:
> > 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
> >
> > чт, 6 сент. 2018 г. в 0:02, Thiago Macieira  > >:
> >
> > On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
> > > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
> > > >> 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
> > Development@qt-project.org 
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Dominik Holland]

Hi,

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

Dominik


Am 09/10/2018 um 12:59 PM schrieb Denis Shienkov:
> 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
>
> чт, 6 сент. 2018 г. в 0:02, Thiago Macieira  >:
>
> On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
> > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
> > >> 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
> Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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

чт, 6 сент. 2018 г. в 0:02, Thiago Macieira :

> On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
> > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
> > >> 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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
> On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
> >> 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Tuesday, 4 September 2018 23:26:27 PDT André Pönitz wrote:
> > 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:

>> 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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Wed, 05 Sep 2018 13:04:39 +0300, Denis Shienkov wrote:

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

Seems to work with Qt5 >= 5.10.

Uwe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[André Pönitz]

On Wed, Sep 05, 2018 at 09:55:41AM -0700, Thiago Macieira wrote:
> On Wednesday, 5 September 2018 02:29:15 PDT Uwe Rathmann wrote:
> > 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'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Wednesday, 5 September 2018 02:29:15 PDT Uwe Rathmann wrote:
> 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.

> 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

> 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

ср, 5 сент. 2018 г. в 12:31, Uwe Rathmann :

> On Wed, 05 Sep 2018 09:56:36 +0100, Sérgio Martins via Development wrote:
>
> >> 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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Wed, 05 Sep 2018 09:56:36 +0100, Sérgio Martins via Development wrote:

>> 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Sérgio Martins via Development]

On 2018-09-05 06:58, Uwe Rathmann wrote:

On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote:


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 ?



export QT_XCB_NATIVE_PAINTING=1


Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

Hi,

> 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


ср, 5 сент. 2018 г. в 9:01, Uwe Rathmann :

> On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote:
>
> > 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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote:

> 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Martin Koller]

On Dienstag, 4. September 2018 12:14:43 CEST Uwe Rathmann wrote:
> On Tue, 04 Sep 2018 12:21:29 +0300, Denis Shienkov wrote:
> 
> > 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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Tuesday, 4 September 2018 08:16:34 PDT Cristian Adam wrote:
> On Tue, Sep 4, 2018 at 4:46 PM Thiago Macieira 
> 
> wrote:
> > 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Cristian Adam]

On Tue, Sep 4, 2018 at 4:46 PM Thiago Macieira 
wrote:

>
> 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Tuesday, 4 September 2018 03:14:43 PDT Uwe Rathmann wrote:
> > 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Tue, 04 Sep 2018 14:38:47 +0300, Denis Shienkov wrote:

> 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Tue, 04 Sep 2018 12:21:29 +0300, Denis Shienkov wrote:

> 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.

> 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.

> 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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

04.09.2018 12:00, 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
Blog entry with some explanations: 
http://www.arnorehn.de/blog/2014/12/quickplot-a-collection-of-native-qtquick-plot-items/


Regards,

Am 29.08.2018 um 19:49 schrieb Denis Shienkov:

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.



29.08.2018 18:56, 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 :)


On 8/29/18 11:39 AM, Denis Shienkov wrote:

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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[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
Blog entry with some explanations: 
http://www.arnorehn.de/blog/2014/12/quickplot-a-collection-of-native-qtquick-plot-items/


Regards,

Am 29.08.2018 um 19:49 schrieb Denis Shienkov:

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.



29.08.2018 18:56, 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 :)


On 8/29/18 11:39 AM, Denis Shienkov wrote:

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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.r...@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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Mon, 03 Sep 2018 12:39:22 -0700, Thiago Macieira wrote:

> 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.

> 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.

> 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






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Monday, 3 September 2018 09:19:31 PDT Uwe Rathmann wrote:
> 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Mon, 03 Sep 2018 16:38:51 +0200, Simon Hausmann wrote:

> ... 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




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Simon Hausmann]

Am 02.09.18 um 20:01 schrieb Thiago Macieira:

On Sunday, 2 September 2018 06:05:57 PDT Uwe Rathmann wrote:

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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Sunday, 2 September 2018 06:05:57 PDT Uwe Rathmann wrote:
> 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Philippe]

> 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

Interesting, the demo works out of the box and is impressive.

Philippe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Sunday, 2 September 2018 05:42:47 PDT Uwe Rathmann wrote:
> 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote:

>> 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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Sun, 02 Sep 2018 14:48:37 +0200, Jean-Michaël Celerier wrote:

> 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Jean-Michaël Celerier]

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


On Sun, Sep 2, 2018 at 2:45 PM Uwe Rathmann 
wrote:

> On Thu, 30 Aug 2018 15:47:34 -0700, Thiago Macieira wrote:
>
> > 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.
>
> > 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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Thu, 30 Aug 2018 15:47:34 -0700, Thiago Macieira wrote:

> 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.

> 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Thursday, 30 August 2018 08:46:32 PDT Uwe Rathmann wrote:
> On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote:
> > 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

Draw it with OpenGL.

> - text

Implemented in QML. Just layer your text over whatever you were painting as a 
background.

> - ...

Use the onion solution: layers!

> 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.

> 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote:

> 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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Thursday, 30 August 2018 06:09:22 PDT Uwe Rathmann wrote:
> 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.

> 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote:

> 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote:

> 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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

чт, 30 авг. 2018 г. в 10:46, Uwe Rathmann :

> On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote:
>
> > 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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Uwe Rathmann]

On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote:

> 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

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.



29.08.2018 18:56, 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 :)


On 8/29/18 11:39 AM, Denis Shienkov wrote:

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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[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 :)


On 8/29/18 11:39 AM, Denis Shienkov wrote:

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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Thiago Macieira]

On Wednesday, 29 August 2018 06:43:40 PDT Denis Shienkov wrote:
> > 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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Denis Shienkov]

> 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

ср, 29 авг. 2018 г. в 15:51, drwho :

> 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 
>  provides API for drawing vector
> graphics, text and images onto different surfaces, or QPaintDevice
> 
>  instances, such as QImage
>  ,
> QOpenGLPaintDevice
> 
> , QWidget
>  ,
> and QPrinter 
> . The actual drawing happens in the
> QPaintDevice 
> 's QPaintEngine
> 
> . The software rasterizer and
> the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine
> 
>  implementations. *The raster
> paint engine is Qt’s software rasterizer, and is used when drawing on a
> QImage 
>  or QWidget
>  .*
> Its strength over the OpenGL paint engine is its high quality when
> antialiasing is enabled, and a complete feature set.”
>
>
> On 29/08/18 06:21 AM, Denis Shienkov wrote:
>
> 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 
>
> #include 
>
> #include 
>
> #include 
>
>  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
>
>
>
> ср, 29 авг. 2018 г. в 12:39, 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 
> listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[drwho]

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  provides API for drawing 
vector graphics, text and images onto different surfaces, or 
QPaintDevice  instances, such 
as QImage , QOpenGLPaintDevice 
, QWidget 
, and QPrinter 
. The actual drawing happens in the 
QPaintDevice 's QPaintEngine 
. The software rasterizer and 
the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine 
 implementations. *The raster 
paint engine is Qt’s software rasterizer, and is used when drawing on a 
QImage  or QWidget 
.* Its strength over the OpenGL 
paint engine is its high quality when antialiasing is enabled, and a 
complete feature set.”



On 29/08/18 06:21 AM, Denis Shienkov wrote:
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
#include
#include
#include
classWidgetfinal:publicQWidget
{
public:
explicitWidget(QWidget*parent=nullptr);
private:
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



ср, 29 авг. 2018 г. в 12:39, 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[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 

#include 

#include 

#include 


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



ср, 29 авг. 2018 г. в 12:39, 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development