Re: [Development] Orphan modules

2018-08-30 Thread Lars Knoll 

On 31 Aug 2018, at 02:06, Chris Adams 
mailto:chris.ad...@qinetic.com.au>> wrote:

Hi Eddy,

I'm willing to be listed as the maintainer of QtFeedback for now.  If
it ever gets more development attention and released as a supported
module then someone with more time to give should probably take over,
but until then I'm more than happy to review any changes people might
contribute for that module.

Thanks Chris! Let’s add you for Qt Feedback then :)

Cheers,
Chris.


On Thu, Aug 30, 2018 at 11:27 PM, Edward Welbourne
mailto:edward.welbou...@qt.io>> wrote:
I notice, as part of seeking folk to look at API reviews, that we have
several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
that brought this to my attention) qtxmlpatterns, according to [0].

* [0] https://wiki.qt.io/Maintainers

The supported modules where we have no maintainer listed go to me for the API 
reviews.

Cheers,
Lars


(There's also qtdoc, with no person as maintainer, but with "Norway" in
the Country column, which I interpret as the doc-team here in Oslo; and
there's qtfeedback, which is unsupported; two other unsupported modules
do in fact have Maintainers.)

If anyone out there feels an urge to volunteer to adopt one of these
orphans, it'd be worth speaking up,

   Eddy.
___
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] Orphan modules

2018-08-30 Thread Chris Adams 
Hi Eddy,

I'm willing to be listed as the maintainer of QtFeedback for now.  If
it ever gets more development attention and released as a supported
module then someone with more time to give should probably take over,
but until then I'm more than happy to review any changes people might
contribute for that module.

Cheers,
Chris.


On Thu, Aug 30, 2018 at 11:27 PM, Edward Welbourne
 wrote:
> I notice, as part of seeking folk to look at API reviews, that we have
> several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
> qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
> that brought this to my attention) qtxmlpatterns, according to [0].
>
> * [0] https://wiki.qt.io/Maintainers
>
> (There's also qtdoc, with no person as maintainer, but with "Norway" in
> the Country column, which I interpret as the doc-team here in Oslo; and
> there's qtfeedback, which is unsupported; two other unsupported modules
> do in fact have Maintainers.)
>
> If anyone out there feels an urge to volunteer to adopt one of these
> orphans, it'd be worth speaking up,
>
> Eddy.
> ___
> 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

2018-08-30 Thread 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] Submitting Qt to oss-fuzz

2018-08-30 Thread Albert Astals Cid via Development 
El dijous, 30 d’agost de 2018, a les 20:42:11 CEST, Albert Astals Cid via 
Development va escriure:
> Unfortunately I have not been able to compile with the memory sanitizer
> enabled yet.

Done :) 

https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/b4f28e7dc5e4b936166cda1be36c3bde6b62c53d

Found https://paste.kde.org/ptyi8utax in under a minute.

Cheers,
  Albert

> 
> Cheers,
>   Albert


-- 
Albert Astals Cid | albert.astals@kdab.com | 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] Submitting Qt to oss-fuzz

2018-08-30 Thread Albert Astals Cid via Development 
El dijous, 30 d’agost de 2018, a les 8:59:40 CEST, André Pönitz va escriure:
> On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via
> 
> Development wrote:
> > I made a local test run of the undefined sanitizer and it found
> > https://paste.kde.org/prkox41mx in a few seconds, so "it works"
> > 
> > If you want to test it locally you can do python infra/helper.py
> > build_fuzzers --sanitizer undefined qt python infra/helper.py
> > run_fuzzer qt qimage_fuzzer for the undefined sanitizer and
> > python infra/helper.py build_fuzzers --sanitizer address qt
> > python infra/helper.py run_fuzzer qt qimage_fuzzer
> > 
> > Unfortunately I have not been able to compile with the memory
> > sanitizer enabled yet.
> > 
> > The most important thing before submitting this upstream is
> > changing the list of trusted addresses the private bugs get sent
> > to.
> > 
> > To have something written i've used my email address but i guess
> > at least i should add eirik.aavitsl...@qt.io (listed as QImage
> > maintainer) there too? Anyone else?  I am not sure how the email
> > address thing works, but i think they need to be "google account"
> > activated, whatever that means, so we can't use
> > secur...@qt-project.org.
> 
> That would be the natural choice.
> 
> > On  poppler i'm using my @gmail.com address and not my @kde.org address
> > since it was just easier.
> > 
> > Comments?
> 
> We are not taking about an innovative approach to coerce people
> into using Google services, right?

Maybe :D

Not really sure how it works, we can try submitting it with security@qt-
project.org and see what happens, but first i'd like confirmation from them 
that they'll look at the errors and confirmation from "the project" that it's 
a good idea to do this.

Cheers,
  Albert

> 
> Andre'


-- 
Albert Astals Cid | albert.astals@kdab.com | 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] Submitting Qt to oss-fuzz

2018-08-30 Thread Lars Knoll 
Hi Albert,

Nice! Robert has been working on exactly the same thing lately. I think it 
would be good if you guys coordinated the effort :)

It would be ideal, if we could somehow get those mails forwarded to the 
security mailing list. I wonder whether we could do that with a special mail 
account that forwards to the security mailing list.

Cheers,
Lars

> On 30 Aug 2018, at 20:42, Albert Astals Cid via Development 
>  wrote:
> 
> oss-fuzz is an online fuzzing service run by Google. 
> 
> They test daily the code base and run fuzzying over it, maintaining a list of 
> open and closed bugs.
> 
> As example you can see one of the poppler issues i fixed at 
>https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382
> 
> Everything is done automatically by a bot, except my "This is fixed by" 
> comment, but that's just there for historical reasons, it's not really needed.
> 
> Found bugs are sent to a list of trusted address and kept private for 90 
> days, then if not fixed then they become public. 
> 
> Fixed bugs become public 30 days after being fixed.
> 
> I have made a qimage fuzzer that uses libpng test files as seed corpus. 
> 
> You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz
> 
> Adding support for Qt is "relatively simple" see 
> https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f
> 
> I made a local test run of the undefined sanitizer and it found 
> https://paste.kde.org/prkox41mx
> in a few seconds, so "it works"
> 
> If you want to test it locally you can do
>python infra/helper.py build_fuzzers --sanitizer undefined qt
>python infra/helper.py run_fuzzer qt qimage_fuzzer
> for the undefined sanitizer and
>python infra/helper.py build_fuzzers --sanitizer address qt
>python infra/helper.py run_fuzzer qt qimage_fuzzer
> 
> Unfortunately I have not been able to compile with the memory sanitizer 
> enabled yet.
> 
> The most important thing before submitting this upstream is changing the list 
> of trusted addresses the private bugs get sent to.
> 
> To have something written i've used my email address but i guess at least i 
> should add eirik.aavitsl...@qt.io (listed as QImage maintainer) there too? 
> Anyone else? 
> 
> I am not sure how the email address thing works, but i think they need to be 
> "google account" activated, whatever that means, so we can't use 
> secur...@qt-project.org. On poppler i'm using my @gmail.com address and not 
> my @kde.org address since it was just easier.
> 
> Comments?
> 
> Cheers,
>  Albert
> 
> -- 
> Albert Astals Cid | albert.astals@kdab.com | 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

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

Re: [Development] Submitting Qt to oss-fuzz

2018-08-30 Thread André Pönitz 
On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via
Development wrote:
> I made a local test run of the undefined sanitizer and it found
> https://paste.kde.org/prkox41mx in a few seconds, so "it works"
> 
> If you want to test it locally you can do python infra/helper.py
> build_fuzzers --sanitizer undefined qt python infra/helper.py
> run_fuzzer qt qimage_fuzzer for the undefined sanitizer and
> python infra/helper.py build_fuzzers --sanitizer address qt
> python infra/helper.py run_fuzzer qt qimage_fuzzer
> 
> Unfortunately I have not been able to compile with the memory
> sanitizer enabled yet.
> 
> The most important thing before submitting this upstream is
> changing the list of trusted addresses the private bugs get sent
> to.
>
> To have something written i've used my email address but i guess
> at least i should add eirik.aavitsl...@qt.io (listed as QImage
> maintainer) there too? Anyone else?  I am not sure how the email
> address thing works, but i think they need to be "google account"
> activated, whatever that means, so we can't use
> secur...@qt-project.org.

That would be the natural choice.

> On  poppler i'm using my @gmail.com address and not my @kde.org address since 
> it was
> just easier.
> 
> Comments?

We are not taking about an innovative approach to coerce people
into using Google services, right?

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

[Development] Submitting Qt to oss-fuzz

2018-08-30 Thread Albert Astals Cid via Development 
oss-fuzz is an online fuzzing service run by Google. 

They test daily the code base and run fuzzying over it, maintaining a list of 
open and closed bugs.

As example you can see one of the poppler issues i fixed at 
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382

Everything is done automatically by a bot, except my "This is fixed by" 
comment, but that's just there for historical reasons, it's not really needed.

Found bugs are sent to a list of trusted address and kept private for 90 days, 
then if not fixed then they become public. 

Fixed bugs become public 30 days after being fixed.

I have made a qimage fuzzer that uses libpng test files as seed corpus. 

You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz

Adding support for Qt is "relatively simple" see 
https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f

I made a local test run of the undefined sanitizer and it found 
https://paste.kde.org/prkox41mx
in a few seconds, so "it works"

If you want to test it locally you can do
python infra/helper.py build_fuzzers --sanitizer undefined qt
python infra/helper.py run_fuzzer qt qimage_fuzzer
for the undefined sanitizer and
python infra/helper.py build_fuzzers --sanitizer address qt
python infra/helper.py run_fuzzer qt qimage_fuzzer

Unfortunately I have not been able to compile with the memory sanitizer enabled 
yet.

The most important thing before submitting this upstream is changing the list 
of trusted addresses the private bugs get sent to.

To have something written i've used my email address but i guess at least i 
should add eirik.aavitsl...@qt.io (listed as QImage maintainer) there too? 
Anyone else? 

I am not sure how the email address thing works, but i think they need to be 
"google account" activated, whatever that means, so we can't use 
secur...@qt-project.org. On poppler i'm using my @gmail.com address and not my 
@kde.org address since it was just easier.

Comments?

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | 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

2018-08-30 Thread 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] Closing issues automatically with new keyword

2018-08-30 Thread Frederik Gladhorn 
On onsdag 29. august 2018 20.17.52 CEST Robert Löhning wrote:
> Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
> > Quick status update from my side:
> > I have the script running against a test installation of JIRA. It seems to
> > work, there are some small issues to be worked out still.
> > 
> > - Qt Creator version numbers are verbose, so I need to be more generous in
> > matching strings, right now I don't detect the version number correctly
> > there. This one I will fix, it's just going to take a few minutes.
> > 
> > - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA
> > versions are 2.x, I consider this a won't fix.
> > 
> > I'd love if people started using "Fixes:", it will work retro-actively.
> > And if you manually close a task in the meantime, no harm is done.
> 
> Looks like somebody should tell the sanity bot:
> https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG

Seems like nobody volunteered (surprise :P).

Sanity bot:
https://codereview.qt-project.org/#/c/238437/1

Commit template:
https://codereview.qt-project.org/#/c/238435/

I now consider the code done, no idea if/where it should live in the future, 
currently it's some internal repo inside TQtC. It's running in a VM and just 
needs the integration to be enabled in the real JIRA instance, so hopefully it 
goes live in the next few days :)

Cheers,
Frederik


> 
> Cheers,
> Robert
> 
> > Multiple fix versions:
> > There were some doubts about which fix versions would be set, for example
> > during the down-merge. This actually turns out to work quite nicely:
> > If a change ends up in dev, the script will detect that it will end up in
> > 5.13.0 right now and sets that as fix version. If the downmerge happens,
> > the script will see the change again in 5.12.0 and add that fix version.
> > In my opinion there is no major harm.
> > If the change is then cherry-picked to 5.9.7, it will also add that fix
> > version.
> > 
> > This also means that changes going into 5.11.4 will be marked as fixed in
> > 5.12.1 or whatever is applicable branch/version wise. So we will actually
> > set fix versions nicely.
> > 
> > There are some fixes in JIRA that would be easy to make, assuming there is
> > agreement. Since I have to use some heuristics, I decided to only ever
> > look at full version numbers, including patch level releases.
> > Currently we have version numbers in JIRA which do not make much sense to
> > me, since they will never be released, such as 6.0, 5.12 and a few more.
> > I would propose we always use the full version, so 6.0.0 and 5.12.0.
> > If the script finds 5.13 but not 5.13.0 it will not set any fix version.
> > 
> > I'm unsure where the whole thing should live, currently it's internal to
> > The Qt Company, I'd love to publish it somewhere (it's a bunch of python
> > files).
> > 
> > Cheers,
> > Frederik
> > 
> > 
> > 
> > ___
> > 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

2018-08-30 Thread 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

2018-08-30 Thread 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

[Development] Orphan modules

2018-08-30 Thread Edward Welbourne 
I notice, as part of seeking folk to look at API reviews, that we have
several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
that brought this to my attention) qtxmlpatterns, according to [0].

* [0] https://wiki.qt.io/Maintainers

(There's also qtdoc, with no person as maintainer, but with "Norway" in
the Country column, which I interpret as the doc-team here in Oslo; and
there's qtfeedback, which is unsupported; two other unsupported modules
do in fact have Maintainers.)

If anyone out there feels an urge to volunteer to adopt one of these
orphans, it'd be worth speaking up,

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

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

2018-08-30 Thread 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

2018-08-30 Thread 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] Closing issues automatically with new keyword

2018-08-30 Thread Shawn Rutledge 

> On 29 Aug 2018, at 20:17, Robert Löhning  wrote:
> 
> Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
>> Quick status update from my side:
>> I have the script running against a test installation of JIRA. It seems to 
>> work, there are some small issues to be worked out still.
>> 
>> - Qt Creator version numbers are verbose, so I need to be more generous in 
>> matching strings, right now I don't detect the version number correctly 
>> there. 
>> This one I will fix, it's just going to take a few minutes.
>> 
>> - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA versions 
>> are 2.x, I consider this a won't fix.
>> 
>> I'd love if people started using "Fixes:", it will work retro-actively. And 
>> if 
>> you manually close a task in the meantime, no harm is done.
> 
> Looks like somebody should tell the sanity bot:
> https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG
> 
> Cheers,
> Robert

Yes.  Also Jira should ideally start showing the patch alongside the bug, as in 
https://bugreports.qt.io/browse/QTCREATORBUG-20991
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-08-30 Thread 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