subject:"\[Interest\] Utilizing the GPU, how to start\?"

Re: [Interest] Utilizing the GPU, how to start?

2016-07-13 Thread Thiago Macieira

Em quarta-feira, 6 de julho de 2016, às 07:54:44 PDT, BAILLY Yves escreveu:
> Need to get rid of QPainter to gain performance? fine! perfect! :-) But no
> need to invent a new language, a new framework, a new API...

Aside from the language, everything else was required.

> Besides, after so many years, QtQuickControls are still way behind QWidgets
> in term of functionality.

When you compare a technology with 15 years of development and bugfixes to one 
with 5, there will be gaps. Add to that hte younger technology also does a lot 
more and is attempting to do in an environment few have good experience with.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-13 Thread BAILLY Yves



> -Original Message-
> From: Interest [mailto:interest-bounces+yves.bailly=verosoftware.com@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Wednesday, July 06, 2016 8:59 AM
> To: interest@qt-project.org
> Subject: Re: [Interest] Utilizing the GPU, how to start?
> 
> [...]
> 
> Long story: let me take us back 8 years.

8 years already? wow... 

> [...]
> So what you want isn't QWidget with OpenGL support. We've proven it
> won't work. What you want is a powerful, Scene Graph-based set of
> widgets with native look and feel (that is Qt Quick Controls).

That set of widgets could be called "QWidget". From a pure user's (the "user" 
here being a developer) perspective, 
whether his (q)widgets-based UI is drawn in an "imperative" way or in a 
"scene-graph" way is mostly irrelevent.
It becomes relevent only when there are visual glitches or performances issues.

Need to get rid of QPainter to gain performance? fine! perfect! :-) But no need 
to invent a new language, a new
framework, a new API... 

Besides, after so many years, QtQuickControls are still way behind QWidgets in 
term of functionality.
 
> You're probably also asking for a C++ API instead of a QML one.

+1 definitely!

--
Yves Bailly
Software Architect


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-12 Thread John C. Turnbull

Thanks very much Sze - they all look very helpful.

Qt is awesome. But it can be "awesomer" ;-)

> On 12 Jul 2016, at 19:41, Sze Howe Koh <szehowe@gmail.com> wrote:
> 
>> On 12 July 2016 at 14:53, John C. Turnbull <ozem...@ozemail.com.au> wrote:
>> Thanks. I never thought of using Google ;-)
>> 
>> Sadly Google shows me what *they* want me to see, not necessarily what I am 
>> actually looking for.
>> 
>> Hence asking the question here: amongst a group of Qt experts who are not 
>> controlled by revenue-generating curating algorithms and who could point me 
>> to the most appropriate articles for my questions.
>> 
>> Thanks for the links. I will check them out and hopefully they will give me 
>> the info I seek.
>> 
>> -jct
>> 
>>> On 12 Jul 2016, at 16:38, Mitch Curtis <mitch.cur...@qt.io> wrote:
>>> 
>>> Have you tried Google? :D These two links probably cover your first two 
>>> questions:
>>> 
>>> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
>>> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
>>> 
>>> 
>>>> -Original Message-
>>>> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
>>>> On Behalf Of John C. Turnbull
>>>> Sent: Tuesday, 12 July 2016 4:06 AM
>>>> To: Uwe Rathmann <uwe.rathm...@tigertal.de>
>>>> Cc: interest@qt-project.org
>>>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>>> 
>>>> Anyone?
>>>> 
>>>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <ozem...@ozemail.com.au>
>>>>> wrote:
>>>>> 
>>>>> I am still new to Qt but am very interested in the technology and the
>>>> deep innards of how it functions. I have worked in a 3D animation studio
>>>> and learned a lot while I was there.
>>>>> 
>>>>> Is there documentation or articles that:
>>>>> 
>>>>> 1) Describe in detail how the Qt Quick rendering pipeline is designed
>>>> and how it operates.
>>>>> 
>>>>> 2) Describe the structure and overall architecture of the Qt Quick
>>>> Scenegraph and how it is rendered?
>>>>> 
>>>>> 3) Describe the steps that have been taken so far and any further steps
>>>> planned to optimise both (1) and (2)?
>>>>> 
>>>>> I really want to know how all this hangs together as I may be able to
>>>> further optimise and improve aspects of them.
>>>>> 
>>>>> -jct
> 
> Hi John,
> 
> In addition to Mitch's links, these might also interest you as you
> mentioned experience in a 3D animation studio:
> * http://doc.qt.io/qt-5/qt3d-overview.html
> * http://doc.qt.io/qt-5/qt3drender-framegraph.html
> 
> As for optimizations for Qt Quick, I think the Qt Company staff
> members involved are in the best position to provide you with the
> relevant info. Note that it is currently summer holidays in Norway, so
> most of the staff are on leave till the end of July. Here's a small
> peek at some of their recent work (although these are components built
> on top of Qt Quick, rather than Qt Quick itself):
> * http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/
> 
> 
> Regards,
> Sze-Howe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-12 Thread Sze Howe Koh

On 12 July 2016 at 14:53, John C. Turnbull <ozem...@ozemail.com.au> wrote:
> Thanks. I never thought of using Google ;-)
>
> Sadly Google shows me what *they* want me to see, not necessarily what I am 
> actually looking for.
>
> Hence asking the question here: amongst a group of Qt experts who are not 
> controlled by revenue-generating curating algorithms and who could point me 
> to the most appropriate articles for my questions.
>
> Thanks for the links. I will check them out and hopefully they will give me 
> the info I seek.
>
> -jct
>
>> On 12 Jul 2016, at 16:38, Mitch Curtis <mitch.cur...@qt.io> wrote:
>>
>> Have you tried Google? :D These two links probably cover your first two 
>> questions:
>>
>> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
>> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
>>
>>
>>> -Original Message-
>>> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
>>> On Behalf Of John C. Turnbull
>>> Sent: Tuesday, 12 July 2016 4:06 AM
>>> To: Uwe Rathmann <uwe.rathm...@tigertal.de>
>>> Cc: interest@qt-project.org
>>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>>
>>> Anyone?
>>>
>>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <ozem...@ozemail.com.au>
>>>> wrote:
>>>>
>>>> I am still new to Qt but am very interested in the technology and the
>>> deep innards of how it functions. I have worked in a 3D animation studio
>>> and learned a lot while I was there.
>>>>
>>>> Is there documentation or articles that:
>>>>
>>>> 1) Describe in detail how the Qt Quick rendering pipeline is designed
>>> and how it operates.
>>>>
>>>> 2) Describe the structure and overall architecture of the Qt Quick
>>> Scenegraph and how it is rendered?
>>>>
>>>> 3) Describe the steps that have been taken so far and any further steps
>>> planned to optimise both (1) and (2)?
>>>>
>>>> I really want to know how all this hangs together as I may be able to
>>> further optimise and improve aspects of them.
>>>>
>>>> -jct

Hi John,

In addition to Mitch's links, these might also interest you as you
mentioned experience in a 3D animation studio:
* http://doc.qt.io/qt-5/qt3d-overview.html
* http://doc.qt.io/qt-5/qt3drender-framegraph.html

As for optimizations for Qt Quick, I think the Qt Company staff
members involved are in the best position to provide you with the
relevant info. Note that it is currently summer holidays in Norway, so
most of the staff are on leave till the end of July. Here's a small
peek at some of their recent work (although these are components built
on top of Qt Quick, rather than Qt Quick itself):
* http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/


Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-12 Thread John C. Turnbull

It's OK - they "do no evil" ;-)

> On 12 Jul 2016, at 17:01, alexander golks <a...@golks.de> wrote:
> 
> Am Tue, 12 Jul 2016 16:53:25 +1000
> schrieb "John C. Turnbull" <ozem...@ozemail.com.au>:
> 
>> Thanks. I never thought of using Google ;-)
>> 
>> Sadly Google shows me what *they* want me to see, not necessarily what I am 
>> actually looking for.
>> 
>> Hence asking the question here: amongst a group of Qt experts who are not 
>> controlled by revenue-generating curating algorithms and who could point me 
>> to the most appropriate articles for my questions.
> 
> pssst they are listening
> 
>> Thanks for the links. I will check them out and hopefully they will give me 
>> the info I seek.
>> 
>> -jct
>> 
>>> On 12 Jul 2016, at 16:38, Mitch Curtis <mitch.cur...@qt.io> wrote:
>>> 
>>> Have you tried Google? :D These two links probably cover your first two 
>>> questions:
>>> 
>>> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
>>> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
>>> 
>>> 
>>>> -Original Message-
>>>> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
>>>> On Behalf Of John C. Turnbull
>>>> Sent: Tuesday, 12 July 2016 4:06 AM
>>>> To: Uwe Rathmann <uwe.rathm...@tigertal.de>
>>>> Cc: interest@qt-project.org
>>>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>>> 
>>>> Anyone?
>>>> 
>>>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <ozem...@ozemail.com.au>  
>>>>> wrote:
>>>>> 
>>>>> I am still new to Qt but am very interested in the technology and the  
>>>> deep innards of how it functions. I have worked in a 3D animation studio
>>>> and learned a lot while I was there.  
>>>>> 
>>>>> Is there documentation or articles that:
>>>>> 
>>>>> 1) Describe in detail how the Qt Quick rendering pipeline is designed  
>>>> and how it operates.  
>>>>> 
>>>>> 2) Describe the structure and overall architecture of the Qt Quick  
>>>> Scenegraph and how it is rendered?  
>>>>> 
>>>>> 3) Describe the steps that have been taken so far and any further steps  
>>>> planned to optimise both (1) and (2)?  
>>>>> 
>>>>> I really want to know how all this hangs together as I may be able to  
>>>> further optimise and improve aspects of them.  
>>>>> 
>>>>> -jct  
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> -- 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-12 Thread alexander golks

Am Tue, 12 Jul 2016 16:53:25 +1000
schrieb "John C. Turnbull" <ozem...@ozemail.com.au>:

> Thanks. I never thought of using Google ;-)
> 
> Sadly Google shows me what *they* want me to see, not necessarily what I am 
> actually looking for.
> 
> Hence asking the question here: amongst a group of Qt experts who are not 
> controlled by revenue-generating curating algorithms and who could point me 
> to the most appropriate articles for my questions.
> 

pssst they are listening

> Thanks for the links. I will check them out and hopefully they will give me 
> the info I seek.
> 
> -jct
> 
> > On 12 Jul 2016, at 16:38, Mitch Curtis <mitch.cur...@qt.io> wrote:
> > 
> > Have you tried Google? :D These two links probably cover your first two 
> > questions:
> > 
> > http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
> > http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
> > 
> >   
> >> -Original Message-
> >> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
> >> On Behalf Of John C. Turnbull
> >> Sent: Tuesday, 12 July 2016 4:06 AM
> >> To: Uwe Rathmann <uwe.rathm...@tigertal.de>
> >> Cc: interest@qt-project.org
> >> Subject: Re: [Interest] Utilizing the GPU, how to start?
> >> 
> >> Anyone?
> >>   
> >>>> On 10 Jul 2016, at 23:23, John C. Turnbull <ozem...@ozemail.com.au>  
> >>> wrote:
> >>> 
> >>> I am still new to Qt but am very interested in the technology and the  
> >> deep innards of how it functions. I have worked in a 3D animation studio
> >> and learned a lot while I was there.  
> >>> 
> >>> Is there documentation or articles that:
> >>> 
> >>> 1) Describe in detail how the Qt Quick rendering pipeline is designed  
> >> and how it operates.  
> >>> 
> >>> 2) Describe the structure and overall architecture of the Qt Quick  
> >> Scenegraph and how it is rendered?  
> >>> 
> >>> 3) Describe the steps that have been taken so far and any further steps  
> >> planned to optimise both (1) and (2)?  
> >>> 
> >>> I really want to know how all this hangs together as I may be able to  
> >> further optimise and improve aspects of them.  
> >>> 
> >>> -jct  
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 


pgpbFmbiRiQEn.pgp
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-12 Thread John C. Turnbull

Thanks. I never thought of using Google ;-)

Sadly Google shows me what *they* want me to see, not necessarily what I am 
actually looking for.

Hence asking the question here: amongst a group of Qt experts who are not 
controlled by revenue-generating curating algorithms and who could point me to 
the most appropriate articles for my questions.

Thanks for the links. I will check them out and hopefully they will give me the 
info I seek.

-jct

> On 12 Jul 2016, at 16:38, Mitch Curtis <mitch.cur...@qt.io> wrote:
> 
> Have you tried Google? :D These two links probably cover your first two 
> questions:
> 
> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
> 
> 
>> -Original Message-
>> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
>> On Behalf Of John C. Turnbull
>> Sent: Tuesday, 12 July 2016 4:06 AM
>> To: Uwe Rathmann <uwe.rathm...@tigertal.de>
>> Cc: interest@qt-project.org
>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>> 
>> Anyone?
>> 
>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <ozem...@ozemail.com.au>
>>> wrote:
>>> 
>>> I am still new to Qt but am very interested in the technology and the
>> deep innards of how it functions. I have worked in a 3D animation studio
>> and learned a lot while I was there.
>>> 
>>> Is there documentation or articles that:
>>> 
>>> 1) Describe in detail how the Qt Quick rendering pipeline is designed
>> and how it operates.
>>> 
>>> 2) Describe the structure and overall architecture of the Qt Quick
>> Scenegraph and how it is rendered?
>>> 
>>> 3) Describe the steps that have been taken so far and any further steps
>> planned to optimise both (1) and (2)?
>>> 
>>> I really want to know how all this hangs together as I may be able to
>> further optimise and improve aspects of them.
>>> 
>>> -jct

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-12 Thread Mitch Curtis

Have you tried Google? :D These two links probably cover your first two 
questions:

http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html


> -Original Message-
> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
> On Behalf Of John C. Turnbull
> Sent: Tuesday, 12 July 2016 4:06 AM
> To: Uwe Rathmann <uwe.rathm...@tigertal.de>
> Cc: interest@qt-project.org
> Subject: Re: [Interest] Utilizing the GPU, how to start?
> 
> Anyone?
> 
> > On 10 Jul 2016, at 23:23, John C. Turnbull <ozem...@ozemail.com.au>
> wrote:
> >
> > I am still new to Qt but am very interested in the technology and the
> deep innards of how it functions. I have worked in a 3D animation studio
> and learned a lot while I was there.
> >
> > Is there documentation or articles that:
> >
> > 1) Describe in detail how the Qt Quick rendering pipeline is designed
> and how it operates.
> >
> > 2) Describe the structure and overall architecture of the Qt Quick
> Scenegraph and how it is rendered?
> >
> > 3) Describe the steps that have been taken so far and any further steps
> planned to optimise both (1) and (2)?
> >
> > I really want to know how all this hangs together as I may be able to
> further optimise and improve aspects of them.
> >
> > -jct
> >
> >>> On 10 Jul 2016, at 22:24, Uwe Rathmann <uwe.rathm...@tigertal.de>
> wrote:
> >>>
> >>> On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote:
> >>>
> >>> This seems _very_ interesting and worth researching, are you going
> >>> to share some results during the QtCon session you mentioned earlier?
> >>
> >> When time has come I will release my package under a Open Source
> >> License, but I first need to reach a certain level of features and
> >> quality. But at least Andrew ( when I can't make it myself ) will have
> the code with him.
> >>
> >> We have not yet decided which details we like to present, but to be
> >> honest I wouldn't consider details of this vertex list generation
> >> being the most interesting aspect. The features are quite obvious,
> >> the implementation is in line with the design of the other QSG
> >> classes ( very similar to what you find in QSGRectangleNode ) -
> >> nothing specific sexy, it's simply: someone has to do it.
> >>
> >> An approach I would prefer to what I have today is some sort of paint
> >> engine. Something you could feed - at least - with a painter path -
> >> that spits out vertex lists.
> >>
> >> Maybe more interesting from my point of view is code, that is
> >> currently implemented inside of QQuick classes, but could be moved to
> >> more lightweight QSG classes. F.e creating texture nodes with
> >> QPainter or the node tree generation for texts ( currently I'm needs
> >> a static QQuickText item as helper ).
> >>
> >> --
> >>
> >> But when it comes to the QQuick classes my way of thinking is often
> >> controversial to the existing code:
> >>
> >> I would like to have the C++ class APIs more compliant with what I
> >> consider being "well established Qt standards".
> >>
> >> The Quick framework itself could be smarter: stuff like not calling
> >> updatePaintNode for invisible items or delaying expensive operations
> >> until updatePolish ( where the layout is stable ) are obvious
> >> examples for how to improve the overall performance.
> >>
> >> Uwe
> >>
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-11 Thread John C. Turnbull

Anyone? 

> On 10 Jul 2016, at 23:23, John C. Turnbull  wrote:
> 
> I am still new to Qt but am very interested in the technology and the deep 
> innards of how it functions. I have worked in a 3D animation studio and 
> learned a lot while I was there.
> 
> Is there documentation or articles that:
> 
> 1) Describe in detail how the Qt Quick rendering pipeline is designed and how 
> it operates.
> 
> 2) Describe the structure and overall architecture of the Qt Quick Scenegraph 
> and how it is rendered?
> 
> 3) Describe the steps that have been taken so far and any further steps 
> planned to optimise both (1) and (2)?
> 
> I really want to know how all this hangs together as I may be able to further 
> optimise and improve aspects of them.
> 
> -jct
> 
>>> On 10 Jul 2016, at 22:24, Uwe Rathmann  wrote:
>>> 
>>> On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote:
>>> 
>>> This seems _very_ interesting and worth researching, are you going to
>>> share some results during the QtCon session you mentioned earlier?
>> 
>> When time has come I will release my package under a Open Source License, 
>> but I first need to reach a certain level of features and quality. But at 
>> least Andrew ( when I can't make it myself ) will have the code with him.
>> 
>> We have not yet decided which details we like to present, but to be 
>> honest I wouldn't consider details of this vertex list generation being 
>> the most interesting aspect. The features are quite obvious, the 
>> implementation is in line with the design of the other QSG classes ( very 
>> similar to what you find in QSGRectangleNode ) - nothing specific sexy, 
>> it's simply: someone has to do it.
>> 
>> An approach I would prefer to what I have today is some sort of paint 
>> engine. Something you could feed - at least - with a painter path - that 
>> spits out vertex lists.
>> 
>> Maybe more interesting from my point of view is code, that is currently 
>> implemented inside of QQuick classes, but could be moved to more 
>> lightweight QSG classes. F.e creating texture nodes with QPainter or the 
>> node tree generation for texts ( currently I'm needs a static QQuickText 
>> item as helper ).
>> 
>> --
>> 
>> But when it comes to the QQuick classes my way of thinking is often 
>> controversial to the existing code:
>> 
>> I would like to have the C++ class APIs more compliant with what I 
>> consider being "well established Qt standards".
>> 
>> The Quick framework itself could be smarter: stuff like not calling 
>> updatePaintNode for invisible items or delaying expensive operations 
>> until updatePolish ( where the layout is stable ) are obvious examples
>> for how to improve the overall performance.
>> 
>> Uwe
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-10 Thread John C. Turnbull

I am still new to Qt but am very interested in the technology and the deep 
innards of how it functions. I have worked in a 3D animation studio and learned 
a lot while I was there.

Is there documentation or articles that:

1) Describe in detail how the Qt Quick rendering pipeline is designed and how 
it operates.

2) Describe the structure and overall architecture of the Qt Quick Scenegraph 
and how it is rendered?

3) Describe the steps that have been taken so far and any further steps planned 
to optimise both (1) and (2)?

I really want to know how all this hangs together as I may be able to further 
optimise and improve aspects of them.

-jct

> On 10 Jul 2016, at 22:24, Uwe Rathmann  wrote:
> 
>> On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote:
>> 
>> This seems _very_ interesting and worth researching, are you going to
>> share some results during the QtCon session you mentioned earlier?
> 
> When time has come I will release my package under a Open Source License, 
> but I first need to reach a certain level of features and quality. But at 
> least Andrew ( when I can't make it myself ) will have the code with him.
> 
> We have not yet decided which details we like to present, but to be 
> honest I wouldn't consider details of this vertex list generation being 
> the most interesting aspect. The features are quite obvious, the 
> implementation is in line with the design of the other QSG classes ( very 
> similar to what you find in QSGRectangleNode ) - nothing specific sexy, 
> it's simply: someone has to do it.
> 
> An approach I would prefer to what I have today is some sort of paint 
> engine. Something you could feed - at least - with a painter path - that 
> spits out vertex lists.
> 
> Maybe more interesting from my point of view is code, that is currently 
> implemented inside of QQuick classes, but could be moved to more 
> lightweight QSG classes. F.e creating texture nodes with QPainter or the 
> node tree generation for texts ( currently I'm needs a static QQuickText 
> item as helper ).
> 
> --
> 
> But when it comes to the QQuick classes my way of thinking is often 
> controversial to the existing code:
> 
> I would like to have the C++ class APIs more compliant with what I 
> consider being "well established Qt standards".
> 
> The Quick framework itself could be smarter: stuff like not calling 
> updatePaintNode for invisible items or delaying expensive operations 
> until updatePolish ( where the layout is stable ) are obvious examples
> for how to improve the overall performance.
> 
> Uwe
> 
> 
> 
> 
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-10 Thread Uwe Rathmann

On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote:

> This seems _very_ interesting and worth researching, are you going to
> share some results during the QtCon session you mentioned earlier?

When time has come I will release my package under a Open Source License, 
but I first need to reach a certain level of features and quality. But at 
least Andrew ( when I can't make it myself ) will have the code with him.

We have not yet decided which details we like to present, but to be 
honest I wouldn't consider details of this vertex list generation being 
the most interesting aspect. The features are quite obvious, the 
implementation is in line with the design of the other QSG classes ( very 
similar to what you find in QSGRectangleNode ) - nothing specific sexy, 
it's simply: someone has to do it.

An approach I would prefer to what I have today is some sort of paint 
engine. Something you could feed - at least - with a painter path - that 
spits out vertex lists.

Maybe more interesting from my point of view is code, that is currently 
implemented inside of QQuick classes, but could be moved to more 
lightweight QSG classes. F.e creating texture nodes with QPainter or the 
node tree generation for texts ( currently I'm needs a static QQuickText 
item as helper ).

--

But when it comes to the QQuick classes my way of thinking is often 
controversial to the existing code:

I would like to have the C++ class APIs more compliant with what I 
consider being "well established Qt standards".

The Quick framework itself could be smarter: stuff like not calling 
updatePaintNode for invisible items or delaying expensive operations 
until updatePolish ( where the layout is stable ) are obvious examples
for how to improve the overall performance.

Uwe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-08 Thread Jason H



> Sent: Friday, July 08, 2016 at 1:11 PM
> From: "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com>
> To: interest@qt-project.org
> Subject: Re: [Interest] Utilizing the GPU, how to start?
>
> Il 06/07/2016 18:19, Jason H ha scritto:
> 
> > What others have not said:
> > I did extensive testing of Qt Quick1 with video playback.
> 
> This is a chapter on its own. (By the way, Qt Quick 1 is still 
> widget-based...)
> 
> In case of video playback, there's much more going on than using the GPU 
> for displaying the video. You want to use the GPU also to decode the 
> video stream (using whatever native APIs you have on your system) and, 
> in order to display it, it's not guaranteed at all the using OpenGL is 
> actually the best way.
> 
> Other overlaying solutions are usually much, much better 
> performance-wise (e.g. VDPAU). But: they don't allow you to embed the 
> video in arbitrary UI hierarchies. Media players usually have very 
> complex setups in order to be able to switch between presentation 
> backends when f.i. you set a videoplayer full screen rather than windowed.

I'm not sure if I am agreeing or conflicting with you, but Anything that can't 
be overlaid today is going to be an issue. You might get minimal CPU on a 
direct render situation, but that's a horrible approach I hope does with the 
old DirectX backends. I much more value the ability to embed video in arbitrary 
hierarchies with alpha-blended overlays.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-08 Thread Giuseppe D'Angelo


Il 06/07/2016 18:19, Jason H ha scritto:


What others have not said:
I did extensive testing of Qt Quick1 with video playback.


This is a chapter on its own. (By the way, Qt Quick 1 is still 
widget-based...)


In case of video playback, there's much more going on than using the GPU 
for displaying the video. You want to use the GPU also to decode the 
video stream (using whatever native APIs you have on your system) and, 
in order to display it, it's not guaranteed at all the using OpenGL is 
actually the best way.


Other overlaying solutions are usually much, much better 
performance-wise (e.g. VDPAU). But: they don't allow you to embed the 
video in arbitrary UI hierarchies. Media players usually have very 
complex setups in order to be able to switch between presentation 
backends when f.i. you set a videoplayer full screen rather than windowed.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-08 Thread Giuseppe D'Angelo


Il 08/07/2016 13:02, Uwe Rathmann ha scritto:

That's why I'm trying to do my controls with scene graph node composition
- as much as possible. But this is no fun either as the feature set
offered by the QSG-nodes ( public or private ) is surprisingly limited
and I had to implement very basic stuff, like creating vertex lists for
gradients ( only vertical linear gradients are there ), raised/ sunken
borders etc.


This seems _very_ interesting and worth researching, are you going to 
share some results during the QtCon session you mentioned earlier?


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-08 Thread Uwe Rathmann

On Fri, 08 Jul 2016 10:19:14 +0100, Giuseppe D'Angelo wrote:

> I think the question was more about measuring CPU and GPU performance
> than memory.

Yes, but as we don't have any problems with the performance of the render 
engine we never benchmarked it. And our problem - the time spent for 
creating the quick item subtree - does not depend on the GPU.

What I did is to check a couple of animations, we need for another 
product comparing Widgets, Quick and OpenGLWidget. All options have been 
fast enough for a pleasing result, but the widget version - no surprise - 
needs for the majority of them more CPU load.

( Unfortunately I had to rule out the QOpenGL path because of certain 
bugs )

> This point about memory usage however is extremely valid, and amongst
> other things shows that allowing styling in QML itself is hard if not
> impossible due to the QObject bloat (and privileging composition over
> vertical integration for "simple" UI elements makes you pay a lot for
> it.)

This is exactly my point - beside, that I believe ( hard to produce 
numbers ), that the consequences of this "bloat" are also significant for 
the overall performance.

That's why I'm trying to do my controls with scene graph node composition 
- as much as possible. But this is no fun either as the feature set 
offered by the QSG-nodes ( public or private ) is surprisingly limited 
and I had to implement very basic stuff, like creating vertex lists for 
gradients ( only vertical linear gradients are there ), raised/ sunken 
borders etc.

Cheers,
Uwe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-07 Thread Sean Harmer


Hi,

On 07/07/2016 07:47, Uwe Rathmann wrote:

On Wed, 06 Jul 2016 18:10:37 +, J-P Nurmi wrote:


Interesting choice. I would have done the exact opposite. Application
logic in C++ and UI declaration in QML.


Well this is actually not a choice - we  did it in QML and ended up with
a disappointing performance, because of QML. And we did it exactly like
you recommend - we simply have a lot of UI.


So what were the results of profiling? CPU usage caused by 
animations/batching, something else? GPU? Bandwidth? Lock contention? 
Any test cases to help others profile it?





Declaring fluid animated UIs in
QML is a joy, writing animations in C++ is not so.


In case of the animations QML offers a compact syntax to access a library
of C++ classes mostly setting up a QPropertyAnimation. Using similar ( or
even the same ) classes from C++ is not uncomfortable either.

My experience so far is, that using Qt/Quick from C++ does not have to be
that different from writing a widget application: creating controls,
setting up signal/slot connections and arranging them into layouts.

The graphic stack behind is irrelevant for the vast majority of the
application code and I disagree with Thiago, that it is not possible to
implement controls with a similar API as their widget counterparts.


That's not true. The CPU just isn't capable of doing lots of blending on 
the number of pixels available on typical displays these days. So it 
depends entirely upon the type of UI you are trying to construct. For 
widget type UIs then yes you should be fine with either tech. Add in 
lots of animations, transparency effects, colour grading effects etc and 
you will very quickly hit limitations of CPU raster based painting.


I'm not saying Qt Quick is perfect. This is why I am asking above about 
what bottleneck you experienced so that we can investigate fixing it.


It's perfectly possible to provide C++ apis, we do this in Qt 3D. It was 
just chosen to not do this for Qt Quick thus far.


Cheers,

Sean



Uwe


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-07 Thread Uwe Rathmann

On Wed, 06 Jul 2016 18:10:37 +, J-P Nurmi wrote:

> Interesting choice. I would have done the exact opposite. Application
> logic in C++ and UI declaration in QML.

Well this is actually not a choice - we  did it in QML and ended up with 
a disappointing performance, because of QML. And we did it exactly like 
you recommend - we simply have a lot of UI.

> Declaring fluid animated UIs in
> QML is a joy, writing animations in C++ is not so.

In case of the animations QML offers a compact syntax to access a library 
of C++ classes mostly setting up a QPropertyAnimation. Using similar ( or 
even the same ) classes from C++ is not uncomfortable either.

My experience so far is, that using Qt/Quick from C++ does not have to be 
that different from writing a widget application: creating controls, 
setting up signal/slot connections and arranging them into layouts.

The graphic stack behind is irrelevant for the vast majority of the 
application code and I disagree with Thiago, that it is not possible to 
implement controls with a similar API as their widget counterparts.

Uwe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-07 Thread André Somers




Op 06/07/2016 om 21:17 schreef André Pönitz:

On Wed, Jul 06, 2016 at 08:34:44AM +0200, André Somers wrote:

Note that even if you define your GUI in QML, you can still do
everything else in C++. The QML doesn't have to be much more than what
you already have as .ui files now, and they are not C++ either are
they?

I keep hearing "If done well, QML is no worse that .ui", but why would
that matter to me? Most of my widgets are done in code, refactoring
typically "just works", and it's typically less(!) lines than doing the
same thing in QML.

I did not mention better or worse. It's different, and it is what you 
need to use to make full use of the GPU. If that is not needed for your 
usecase, widgets may suit your needs better. Great! There is nothing 
wrong with widgets if you ask me, and I think that there is still plenty 
of room for development there even if the official status is "done". But 
it is never going to be as performant graphically as Quick 2 is. As long 
as you ('all) are aware of its limitations, it's still a great and 
mature technology.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Thiago Macieira

On quinta-feira, 7 de julho de 2016 01:03:23 PDT André Pönitz wrote:
> On Wed, Jul 06, 2016 at 02:16:46PM -0700, Thiago Macieira wrote:
> > On quarta-feira, 6 de julho de 2016 20:23:44 PDT André Pönitz wrote:
> > > > Stop using QtWidgets, including QtWebView and QLabel, and transition
> > > > to Qt Quick instead. Qt Quick uses the GPU, QtWidgets do not.
> > > 
> > > So to use a certain backend technology you seriously advice to
> > > switch fronend languages, too?
> > 
> > That's the only option provided. You can choose one of:
> > 
> > a) port
> > b) keep it as it is
> 
> I guess it depends a bit on how "Qt widgets to take advantage of a GPU"
> is to be interpreted. I don't think that special GPU support for painting
> some QPushButton was asked for. Playing a video inside a QWidget based
> application might be closer.
> 
> When I look at my second monitor right now I see kaffeine (something
> capable of playing videos with a Qt Widgets GUI) running, and if I am to
> believe intel_gpu_top output it does utilize the GPU.
> 
> Some _something_ with Media, Widgets and GPU (keywords from the original
> mail) works in practice.

The way I see it, any video player that doesn't default to HW acceleration is 
not worth its salt.

I'd expect that if you want to force it to CPU-only, you'd have to do 
something. Maybe disabling the CPU fallback would also be opt-in.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread André Pönitz

On Wed, Jul 06, 2016 at 02:16:46PM -0700, Thiago Macieira wrote:
> On quarta-feira, 6 de julho de 2016 20:23:44 PDT André Pönitz wrote:
> > > Stop using QtWidgets, including QtWebView and QLabel, and transition
> > > to Qt Quick instead. Qt Quick uses the GPU, QtWidgets do not.
> > 
> > So to use a certain backend technology you seriously advice to
> > switch fronend languages, too?
> 
> That's the only option provided. You can choose one of:
> 
> a) port
> b) keep it as it is

I guess it depends a bit on how "Qt widgets to take advantage of a GPU"
is to be interpreted. I don't think that special GPU support for painting
some QPushButton was asked for. Playing a video inside a QWidget based
application might be closer.

When I look at my second monitor right now I see kaffeine (something
capable of playing videos with a Qt Widgets GUI) running, and if I am to
believe intel_gpu_top output it does utilize the GPU. 

Some _something_ with Media, Widgets and GPU (keywords from the original
mail) works in practice.

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

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Thiago Macieira

On quarta-feira, 6 de julho de 2016 20:23:44 PDT André Pönitz wrote:
> > Stop using QtWidgets, including QtWebView and QLabel, and transition
> > to Qt Quick instead. Qt Quick uses the GPU, QtWidgets do not.
> 
> So to use a certain backend technology you seriously advice to
> switch fronend languages, too?

That's the only option provided. You can choose one of:

a) port
b) keep it as it is

There are no other, current options. People could invest time in providing an 
alternative, like Uwe is doing, but that currently is not available.

> When did *you personally* attempt to port a GUI project from
> Widgets to Quick?

All of my GUI projects have been ported.

That is, with a figure of speech. Mathematically speaking, I get a SIGFPE when 
calculating the percentage of my GUI projects ported to Qt Quick.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread André Pönitz

On Wed, Jul 06, 2016 at 06:10:37PM +, J-P Nurmi wrote:
> > On 06 Jul 2016, at 19:41, Uwe Rathmann 
> > wrote:
> > 
> >> On Tue, 05 Jul 2016 23:58:48 -0700, Thiago Macieira wrote:
> >> 
> >> So what you want isn't QWidget with OpenGL support. We've proven it
> >> won't work. What you want is a powerful, Scene Graph-based set of
> >> widgets with native look and feel (that is Qt Quick Controls).
> >> 
> >> You're probably also asking for a C++ API instead of a QML one.
> > 
> > And this is exactly what I'm currently trying to do - creating a set
> > of Quick controls offering full featured C++ and QML APIs.
> > 
> > Our main motivation is the well known instantiation problem of QML,
> > that is totally dominating the overall performance of our user
> > interface. As most of our QML code is application code, having a C++
> > API for the controls is mandatory to significantly limit the amount
> > of QML.
> 
> Interesting choice. I would have done the exact opposite. Application
> logic in C++ and UI declaration in QML. Declaring fluid animated UIs
> in QML is a joy, writing animations in C++ is not so.

Right, but not because C++ is insufficient for the task, but because
it is "impossible" to disantangle the JSON-ish and the JS parts of
Qt Quick and easily re-use the same backend implementation with
a plain C++ interface.

Stuffing a few items into a JSON-style property bag is a no-brainer in
C++. Last time I looked there was even something called 'QtJson' which
pretty much looked like a Qt/C++ JSON implementation.

Intesting enough, stuffing a few properties into a bag and optionally
add an event handler or two is also what a typical Widget use looks
like. So this is clearly possible in C++.

The JavaScript part in Qt Quick is of course uglier to avoid. But we all
know that this absolutely and really does not exist (If it would, Qt
Quick wouldn't be "declarative", right?), and if it accidentally existed
it would not be compulsory to use, and if it acccidentally would be.
recommended best practice would of course be to avoid it, and in case
usage is unavoidable...  oh, well, it does not exist, right?

So where exactly is the *real* problem that there is no C++ interface
to "fluid animated UIs"?

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

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Scott Aron Bloom

On Tue, Jul 05, 2016 at 05:41:33PM -0700, Thiago Macieira wrote:
> On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
> > How does one get Qt widgets to take advantage of a GPU?  If this 
> > question seem naïve, it is because it is.
> > 
> > With my application, I am displaying different types of media — mp4 
> > (using QMedia Player) Html (folders containing a "mini-site” using
> > QWebView) Images (using a Qlabel)
> > 
> > This Qt 5.5, Windows7/10, running on a low end compute stick.  The 
> > CPU seems to take the brunt of the performance.  Just wondering how 
> > to offload some of that?
> 
> Stop using QtWidgets, including QtWebView and QLabel, and transition 
> to Qt Quick instead. Qt Quick uses the GPU, QtWidgets do not.

So to use a certain backend technology you seriously advice to switch fronend 
languages, too?

When did *you personally* attempt to port a GUI project from Widgets to Quick?

Amdre'


I know I never finished one conversion attempt...  Except for the most simple 
of UI's with very little NON-UI logic 

Scott
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread André Pönitz

On Tue, Jul 05, 2016 at 05:41:33PM -0700, Thiago Macieira wrote:
> On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
> > How does one get Qt widgets to take advantage of a GPU?  If this
> > question seem naïve, it is because it is.
> > 
> > With my application, I am displaying different types of media — mp4
> > (using QMedia Player) Html (folders containing a "mini-site” using
> > QWebView) Images (using a Qlabel)
> > 
> > This Qt 5.5, Windows7/10, running on a low end compute stick.  The
> > CPU seems to take the brunt of the performance.  Just wondering how
> > to offload some of that?
> 
> Stop using QtWidgets, including QtWebView and QLabel, and transition
> to Qt Quick instead. Qt Quick uses the GPU, QtWidgets do not.

So to use a certain backend technology you seriously advice to
switch fronend languages, too?

When did *you personally* attempt to port a GUI project from
Widgets to Quick?

Amdre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread J-P Nurmi

> On 06 Jul 2016, at 19:41, Uwe Rathmann  wrote:
> 
>> On Tue, 05 Jul 2016 23:58:48 -0700, Thiago Macieira wrote:
>> 
>> So what you want isn't QWidget with OpenGL support. We've proven it
>> won't work. What you want is a powerful, Scene Graph-based set of
>> widgets with native look and feel (that is Qt Quick Controls).
>> 
>> You're probably also asking for a C++ API instead of a QML one.
> 
> And this is exactly what I'm currently trying to do - creating a set of 
> Quick controls offering full featured C++ and QML APIs.
> 
> Our main motivation is the well known instantiation problem of QML, that 
> is totally dominating the overall performance of our user interface. As 
> most of our QML code is application code, having a C++ API for the 
> controls is mandatory to significantly limit the amount of QML.

Interesting choice. I would have done the exact opposite. Application logic in 
C++ and UI declaration in QML. Declaring fluid animated UIs in QML is a joy, 
writing animations in C++ is not so.

--
J-P Nurmi
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Uwe Rathmann

On Tue, 05 Jul 2016 23:58:48 -0700, Thiago Macieira wrote:

> So what you want isn't QWidget with OpenGL support. We've proven it
> won't work. What you want is a powerful, Scene Graph-based set of
> widgets with native look and feel (that is Qt Quick Controls).
> 
> You're probably also asking for a C++ API instead of a QML one.

And this is exactly what I'm currently trying to do - creating a set of 
Quick controls offering full featured C++ and QML APIs.

Our main motivation is the well known instantiation problem of QML, that 
is totally dominating the overall performance of our user interface. As 
most of our QML code is application code, having a C++ API for the 
controls is mandatory to significantly limit the amount of QML.

We will present some results from this attempt at the QtCon: https://
conf.qtcon.org/en/qtcon/public/events/428

Uwe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Jason H

Don't worry anout using the GPU. As others have said, you can't with widgets. But the overall drawing is good. Also like others have said use QtQuick2.

What others have not said:

I did extensive testing of Qt Quick1 with video playback. What I found was having the media backend properly configured to use hardware made the biggest difference. If you are playing MP4, then make sure your media player backend (there are several possible on Windows) and your codecs are all hardware accelerated. This is really want you need. I had an intel Atom that was sucking down 80-90% to play video, leaving not much for the UI. A few tweaks later, the video playback was only taking 10% and things were good again. I'd say move to QtQuick2 and check your media backend. My experience was on XP, so you're on your own.

Sent: Tuesday, July 05, 2016 at 2:45 PM
From: "Jason Kretzer" <ja...@gocodigo.com>
To: "interest@qt-project.org" <interest@qt-project.org>
Subject: [Interest] Utilizing the GPU, how to start?

How does one get Qt widgets to take advantage of a GPU? If this question seem naïve, it is because it is.

With my application, I am displaying different types of media —

mp4 (using QMedia Player)

Html (folders containing a "mini-site” using QWebView)

Images (using a Qlabel)

This Qt 5.5, Windows7/10, running on a low end compute stick. The CPU seems to take the brunt of the performance. Just wondering how to offload some of that?

Thanks,

-Jason

//--//

Jason R. Kretzer

Lead Application Developer

ja...@gocodigo.com

//--//

“quidquid latine dictum sit altum videtur"

___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread John C. Turnbull

Thanks.

I certainly see Vulkan very much as a "future" prospect as it is clearly not 
even relevant in the technology world to any great extent at the moment.

I was just curious if Vulkan had been considered and I am very pleased that it 
is "on the radar" where it should be.

-jct

> On 6 Jul 2016, at 20:26, Sean Harmer  wrote:
> 
> 
> 
>> On 06/07/2016 10:41, John C. Turnbull wrote:
>> Thanks - great to hear!
>> 
>> I am a firm believer in the significance that Vulkan will play in the future 
>> of GPU based applications.
> 
> That's also my view. However, we are not yet at the stage where the graphics 
> API is the bottleneck for most work loads, especially with Qt Quick. Even 
> in Qt 3D we are still bottle-necked by the CPU work that needs to be done 
> prior to the CPU load of submitting the actual OpenGL calls.
> 
> For Qt Quick there is a lot of lower hanging fruit to be tackled than 
> providing a Vulkan backend. Laszlo is doing great work in abstracting the Qt 
> Quick renderer to make it work with other backends which will enable a Vulkan 
> renderer in the future - along with DX12 and Metal.
> 
> Qt 3D already has an architecture that would make it relatively easy to add 
> backends for other graphics API but again, we have plenty of other stuff 
> to tackle before OpenGL becomes the bottleneck. Especially since Qt 3D can 
> already take advantage of instanced rendering, compressed textures, texture 
> arrays, UBOs and compute shaders. Until we can be convinced that Vulkan would 
> remove a large bottle neck we will likely continue adding more features, 
> examples, documentation, fixing bugs and optimising performance. But rest 
> assured, Vulkan is on the radar.
> 
> Cheers,
> 
> Sean
> 
>> 
>> On 6 Jul 2016, at 18:33, Dmitry Volosnykh  wrote:
>> 
>>> John, here you are: https://blog.qt.io/?s=vulkan=en
>>> 
 On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull  
 wrote:
 Just out of interest, has anyone within the Qt community or company 
 considered Vulkan?
 
 It looks to me as though the future of low level graphics APIs is not 
 OpenGL or Direct3D or Metal.
 
 It's Vulkan.
 
 > On 6 Jul 2016, at 17:53, Kai Koehne  wrote:
 >
 >
 >
 >> -Original Message-
 >> From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org]
 >> [...]
 >> Multimedia and web rendering are a different story.  Others are better
 >> qualified to comment on the details of how WebEngine, QtMultimedia, and
 >> the older alternatives are implemented - but they are all wrappers 
 >> around
 >> other libraries.  Just because widgets don’t render their own pixels on 
 >> the
 >> GPU doesn’t mean those libraries can’t render the framed content on the
 >> GPU, AFAIK.  At least theoretically, but I’m not up-to-date on whether 
 >> the
 >> widget implementations are currently doing that efficiently.
 >
 > QWeb_Engine_View indeed uses Qt Quick (and therefore potentially
 > the GPU) underneath , even for the widgets integration. So it might be 
 > worth
 > a try porting your app from Qt WebKit to Qt WebEngine (if only because
 > Qt WebKit is deprecated).
 >
 > For the video, it looks like QVideoWidget might benefit from OpenGL if
 > it's parent is a QOpenGL widget. Maybe you can experiment with this.
 > (I don't have first hand experience with QVideoWidget though).
 >
 >
 >
 > Regards
 >
 > Kai
 > ___
 > Interest mailing list
 > Interest@qt-project.org
 > http://lists.qt-project.org/mailman/listinfo/interest
 
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest
>> 
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Sean Harmer

On 06/07/2016 10:41, John C. Turnbull wrote:

Thanks - great to hear!

I am a firm believer in the significance that Vulkan will play in the 
future of GPU based applications.

That's also my view. However, we are not yet at the stage where the 
graphics API is the bottleneck for most work loads, especially with Qt 
Quick. Even in Qt 3D we are still bottle-necked by the CPU work that 
needs to be done prior to the CPU load of submitting the actual OpenGL 
calls.

For Qt Quick there is a lot of lower hanging fruit to be tackled than 
providing a Vulkan backend. Laszlo is doing great work in abstracting 
the Qt Quick renderer to make it work with other backends which will 
enable a Vulkan renderer in the future - along with DX12 and Metal.

Qt 3D already has an architecture that would make it relatively easy to 
add backends for other graphics API but again, we have plenty of other 
stuff to tackle before OpenGL becomes the bottleneck. Especially since 
Qt 3D can already take advantage of instanced rendering, compressed 
textures, texture arrays, UBOs and compute shaders. Until we can be 
convinced that Vulkan would remove a large bottle neck we will likely 
continue adding more features, examples, documentation, fixing bugs and 
optimising performance. But rest assured, Vulkan is on the radar.

Cheers,

Sean

On 6 Jul 2016, at 18:33, Dmitry Volosnykh > wrote:

John, here you are: https://blog.qt.io/?s=vulkan=en

On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull 
> wrote:

Just out of interest, has anyone within the Qt community or
company considered Vulkan?

It looks to me as though the future of low level graphics APIs is
not OpenGL or Direct3D or Metal.

It's Vulkan.

> On 6 Jul 2016, at 17:53, Kai Koehne > wrote:
>
>
>
>> -Original Message-
>> From: Interest [mailto:interest-bounces+kai.koehne
=qt...@qt-project.org
]
>> [...]
>> Multimedia and web rendering are a different story.  Others
are better
>> qualified to comment on the details of how WebEngine,
QtMultimedia, and
>> the older alternatives are implemented - but they are all
wrappers around
>> other libraries.  Just because widgets don’t render their own
pixels on the
>> GPU doesn’t mean those libraries can’t render the framed
content on the
>> GPU, AFAIK.  At least theoretically, but I’m not up-to-date on
whether the
>> widget implementations are currently doing that efficiently.
>
> QWeb_Engine_View indeed uses Qt Quick (and therefore potentially
> the GPU) underneath , even for the widgets integration. So it
might be worth
> a try porting your app from Qt WebKit to Qt WebEngine (if only
because
> Qt WebKit is deprecated).
>
> For the video, it looks like QVideoWidget might benefit from
OpenGL if
> it's parent is a QOpenGL widget. Maybe you can experiment with
this.
> (I don't have first hand experience with QVideoWidget though).
>
>
>
> Regards
>
> Kai
> ___
> Interest mailing list
> Interest@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Giuseppe D'Angelo

On Wed, Jul 6, 2016 at 11:41 AM, John C. Turnbull
 wrote:
> I am a firm believer in the significance that Vulkan will play in the future
> of GPU based applications.

Note that there's still a huge lack of Vulkan drivers for low end
devices, and it won't help at all unless you are bottlenecked by the
driver and the command submission, the latter of which can be worked
around in OpenGL by using command buffers, and both of which are
currently not the main bottleneck of the QQ2 renderer...

Cheers,
-- 
Giuseppe D'Angelo
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread John C. Turnbull

Thanks - great to hear!

I am a firm believer in the significance that Vulkan will play in the future of 
GPU based applications.

> On 6 Jul 2016, at 18:33, Dmitry Volosnykh  wrote:
> 
> John, here you are: https://blog.qt.io/?s=vulkan=en
> 
>> On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull  
>> wrote:
>> Just out of interest, has anyone within the Qt community or company 
>> considered Vulkan?
>> 
>> It looks to me as though the future of low level graphics APIs is not OpenGL 
>> or Direct3D or Metal.
>> 
>> It's Vulkan.
>> 
>> > On 6 Jul 2016, at 17:53, Kai Koehne  wrote:
>> >
>> >
>> >
>> >> -Original Message-
>> >> From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org]
>> >> [...]
>> >> Multimedia and web rendering are a different story.  Others are better
>> >> qualified to comment on the details of how WebEngine, QtMultimedia, and
>> >> the older alternatives are implemented - but they are all wrappers around
>> >> other libraries.  Just because widgets don’t render their own pixels on 
>> >> the
>> >> GPU doesn’t mean those libraries can’t render the framed content on the
>> >> GPU, AFAIK.  At least theoretically, but I’m not up-to-date on whether the
>> >> widget implementations are currently doing that efficiently.
>> >
>> > QWeb_Engine_View indeed uses Qt Quick (and therefore potentially
>> > the GPU) underneath , even for the widgets integration. So it might be 
>> > worth
>> > a try porting your app from Qt WebKit to Qt WebEngine (if only because
>> > Qt WebKit is deprecated).
>> >
>> > For the video, it looks like QVideoWidget might benefit from OpenGL if
>> > it's parent is a QOpenGL widget. Maybe you can experiment with this.
>> > (I don't have first hand experience with QVideoWidget though).
>> >
>> >
>> >
>> > Regards
>> >
>> > Kai
>> > ___
>> > Interest mailing list
>> > Interest@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/interest
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Dmitry Volosnykh

John, here you are: https://blog.qt.io/?s=vulkan=en

On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull 
wrote:

> Just out of interest, has anyone within the Qt community or company
> considered Vulkan?
>
> It looks to me as though the future of low level graphics APIs is not
> OpenGL or Direct3D or Metal.
>
> It's Vulkan.
>
> > On 6 Jul 2016, at 17:53, Kai Koehne  wrote:
> >
> >
> >
> >> -Original Message-
> >> From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org
> ]
> >> [...]
> >> Multimedia and web rendering are a different story.  Others are better
> >> qualified to comment on the details of how WebEngine, QtMultimedia, and
> >> the older alternatives are implemented - but they are all wrappers
> around
> >> other libraries.  Just because widgets don’t render their own pixels on
> the
> >> GPU doesn’t mean those libraries can’t render the framed content on the
> >> GPU, AFAIK.  At least theoretically, but I’m not up-to-date on whether
> the
> >> widget implementations are currently doing that efficiently.
> >
> > QWeb_Engine_View indeed uses Qt Quick (and therefore potentially
> > the GPU) underneath , even for the widgets integration. So it might be
> worth
> > a try porting your app from Qt WebKit to Qt WebEngine (if only because
> > Qt WebKit is deprecated).
> >
> > For the video, it looks like QVideoWidget might benefit from OpenGL if
> > it's parent is a QOpenGL widget. Maybe you can experiment with this.
> > (I don't have first hand experience with QVideoWidget though).
> >
> >
> >
> > Regards
> >
> > Kai
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread John C. Turnbull

Just out of interest, has anyone within the Qt community or company considered 
Vulkan?

It looks to me as though the future of low level graphics APIs is not OpenGL or 
Direct3D or Metal.

It's Vulkan.

> On 6 Jul 2016, at 17:53, Kai Koehne  wrote:
> 
> 
> 
>> -Original Message-
>> From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org]
>> [...]
>> Multimedia and web rendering are a different story.  Others are better
>> qualified to comment on the details of how WebEngine, QtMultimedia, and
>> the older alternatives are implemented - but they are all wrappers around
>> other libraries.  Just because widgets don’t render their own pixels on the
>> GPU doesn’t mean those libraries can’t render the framed content on the
>> GPU, AFAIK.  At least theoretically, but I’m not up-to-date on whether the
>> widget implementations are currently doing that efficiently.
> 
> QWeb_Engine_View indeed uses Qt Quick (and therefore potentially
> the GPU) underneath , even for the widgets integration. So it might be worth
> a try porting your app from Qt WebKit to Qt WebEngine (if only because 
> Qt WebKit is deprecated).
> 
> For the video, it looks like QVideoWidget might benefit from OpenGL if
> it's parent is a QOpenGL widget. Maybe you can experiment with this.
> (I don't have first hand experience with QVideoWidget though).
> 
> 
> 
> Regards
> 
> Kai
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Kai Koehne



> -Original Message-
> From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org]
> [...]
> Multimedia and web rendering are a different story.  Others are better
> qualified to comment on the details of how WebEngine, QtMultimedia, and
> the older alternatives are implemented - but they are all wrappers around
> other libraries.  Just because widgets don’t render their own pixels on the
> GPU doesn’t mean those libraries can’t render the framed content on the
> GPU, AFAIK.  At least theoretically, but I’m not up-to-date on whether the
> widget implementations are currently doing that efficiently.

QWeb_Engine_View indeed uses Qt Quick (and therefore potentially
the GPU) underneath , even for the widgets integration. So it might be worth
a try porting your app from Qt WebKit to Qt WebEngine (if only because 
Qt WebKit is deprecated).

For the video, it looks like QVideoWidget might benefit from OpenGL if
it's parent is a QOpenGL widget. Maybe you can experiment with this.
(I don't have first hand experience with QVideoWidget though).



Regards

Kai
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Shawn Rutledge

> On 6 Jul 2016, at 08:34, André Somers <an...@familiesomers.nl> wrote:
> 
> Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:
>> 
>> -Original Message-
>> From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
>> Behalf Of Thiago Macieira
>> Sent: Tuesday, July 5, 2016 5:42 PM
>> To: interest@qt-project.org
>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>> 
>> On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
>>> How does one get Qt widgets to take advantage of a GPU?  If this
>>> question seem naïve, it is because it is.
>>> 
>>> With my application, I am displaying different types of media —
>>> mp4 (using QMedia Player)
>>> Html (folders containing a "mini-site” using QWebView) Images (using a
>>> Qlabel)
>>> 
>>> This Qt 5.5, Windows7/10, running on a low end compute stick.

Hmm, how low-end can it be if it can run Windows?

Why 5.5?  At least 5.6 is LTS, so if you find any bugs, they’d have a chance of 
getting fixed in future 5.6 releases.

>>>  The CPU
>>> seems to take the brunt of the performance.  Just wondering how to
>>> offload some of that?
>> Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt 
>> Quick instead. Qt Quick uses the GPU, QtWidgets do not.
>> ==
>> 
>> That’s a pretty horrible answer... There are MANY of us, who prefer for all 
>> sorts of reasons, to use C++ as our primary development language.

Yeah we hear that feedback a lot.

>> Is there no outlook for QtWidgets to start using the GPU?
>> 
> No, there is not. Not realisticly. First of all, widgets are "done", so not 
> much development is going on there. But more important is that the way 
> widgets are rendered simply doesn't suit the way modern GPU's work. It is the 
> main reason Quick (2) was created in the first place: render the contents in 
> such a way that it can utilize the GPU the way its meant to be used. That 
> can't be retrofitted to the widgets world.

What that means (from my understanding so far) is that if you try to render 
widgets with OpenGL, you will end up with a lot of draw calls, because widgets 
are rendered individually, in paint order (bottom up).  So there might not be a 
worthwhile speedup.  Whereas OpenGL works better to render a larger number of 
vertices in one draw call, which is why the QtQuick scene graph uses batching 
to group together items which use the same shaders and same uniforms, and which 
aren’t separated by other different items at intervening Z layers.  But it 
doesn’t sound like rendering the widgets themselves is going to be the 
bottleneck in your application anyway, as long as you can prevent the widgets 
themselves from being re-rendered too often.  I.e. no animations, and no widget 
overlays on top of the dynamic content.

Multimedia and web rendering are a different story.  Others are better 
qualified to comment on the details of how WebEngine, QtMultimedia, and the 
older alternatives are implemented - but they are all wrappers around other 
libraries.  Just because widgets don’t render their own pixels on the GPU 
doesn’t mean those libraries can’t render the framed content on the GPU, AFAIK. 
 At least theoretically, but I’m not up-to-date on whether the widget 
implementations are currently doing that efficiently.

> Note that even if you define your GUI in QML, you can still do everything 
> else in C++. The QML doesn't have to be much more than what you already have 
> as .ui files now, and they are not C++ either are they? Difference is of 
> course that they get compiled into C++, where QML is not.

But you can use the QML compiler.  It translates the QML to C++ and compiles 
that.

It doesn’t hurt to try QtQuick, anyway.  If your UI is not complex, you can 
throw together a QML prototype in a few hours and see whether it performs 
better.  We have examples for both media-playing and web browsing, so you could 
start by checking performance of those.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread Thiago Macieira

On quarta-feira, 6 de julho de 2016 00:56:04 PDT Scott Aron Bloom wrote:
> Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt
> Quick instead. Qt Quick uses the GPU, QtWidgets do not.
> ==
> 
> That’s a pretty horrible answer... There are MANY of us, who prefer for all
> sorts of reasons, to use C++ as our primary development language.

> Is there no outlook for QtWidgets to start using the GPU?

No. Long story short: the QPainter model is incompatible with OpenGL. We 
tried, we failed. So we created a new one that works as OpenGL expects and 
it's called "Qt Quick 2".

Alternative long story short: we've already done that work and the result is 
Qt Quick 2 and Qt Quick Controls.

Long story: let me take us back 8 years. 

Before Qt 4.5, used the "native" engine for painting on X11 and on Mac, and it 
had a really horrible GDI engine for Windows, so it had a replacement engine 
that used its own internal painting mechanism using QImage. Because of that, 
it was called the "raster" engine.

The XRender engine for X11 was much faster than "raster", but it produced 
subtly different output depnding on the X11 version, the number of bugfixes 
applied (and X.org developers were then invariably GNOME users, which meant 
they never tested Qt) and very different from Mac and Windows.

The best of both worlds would be to make the raster engine as fast as the 
native, of course. But how?

Well, turns out that the GPU is very good at doing graphics. And we have an 
API to access the GPU, it's called OpenGL. So Qt 4.5, in addition optimising 
the raster engine and making the graphics system selectable at runtime, 
introduced a new, experimental graphics system called "opengl". This was 
called "Falcon Project".

Those of you who have tried the opengl graphics system in Qt 4.5-4.8 know how 
buggy it was. We never made it work properly, for many reasons, including some 
that were the same as the native graphics system problems: OpenGL drivers work 
differently from one another.

Most importantly, the imperative painting model that QPainter and, by 
extension, QWidget use, is incompatible with how GPUs operate. You can do it, 
but it's not very efficient. Right around that time, the MeeGo project was 
starting and the Qt developers were comparing notes with the Clutter 
developers. Clutter was around this time developing a backend called "Clutter 
on OpenGL" (COGL), which was like the Qt's opengl graphics system, but with 
one twist: it would defer all painting operations into a journal and then 
reorder them as necessary to be efficient with the GPU.

Qt developers looked at that and decided it was overly complex and didn't go 
far enough, not to mention that all Clutter developers, being employed by 
Intel, were optimising only for the Intel GPUs (yeah, I work for Intel now). 
From what I understand from the developers at this time, the most problematic 
issue with OpenGL was saving state between frames. With an imperative painting 
model, the engine cannot know what's going to happen on the next frame, so it 
cannot know what to cache and what to discard. If you cache too little, you 
spend time re-uploading resources to the GPU and re-rendering things; if you 
cache too much, you're wasting resources.

So around the time that Qt 4.8 was launching, we kicked off a new project that 
tried to use OpenGL the way that it was designed to be used, like games do. 
This project was called "Scene Graph" and is fundamentally different from 
QPainter that it works in *retained* mode instead of imperative mode. The 
graph of that Scene Graph *is* the cache: while the graph node is present, its 
associated GPU resource is kept; when it's removed, the resource is discarded. 
All the engine needs to know is the order in which the OpenGL resources should 
be sent to the GPU when rendering the frame. And note that this can be pre-
calculated and stored, instead of re-calculated in each frame.

This is also the reason why Qt 5.0 came with Qt Quick 1 (based on 
QGraphicsView, which means QPainter) and Qt Quick 2, which is designed around 
OpenGL. That in turn is the reason why there was a requirement of OpenGL for 
Qt Quick 2 and why version 1 was deprecated then.

So what you want isn't QWidget with OpenGL support. We've proven it won't 
work. What you want is a powerful, Scene Graph-based set of widgets with 
native look and feel (that is Qt Quick Controls). 

You're probably also asking for a C++ API instead of a QML one.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-06 Thread André Somers




Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:


-Original Message-
From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
Behalf Of Thiago Macieira
Sent: Tuesday, July 5, 2016 5:42 PM
To: interest@qt-project.org
Subject: Re: [Interest] Utilizing the GPU, how to start?

On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:

How does one get Qt widgets to take advantage of a GPU?  If this
question seem naïve, it is because it is.

With my application, I am displaying different types of media —
mp4 (using QMedia Player)
Html (folders containing a "mini-site” using QWebView) Images (using a
Qlabel)

This Qt 5.5, Windows7/10, running on a low end compute stick.  The CPU
seems to take the brunt of the performance.  Just wondering how to
offload some of that?

Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt 
Quick instead. Qt Quick uses the GPU, QtWidgets do not.
==

That’s a pretty horrible answer... There are MANY of us, who prefer for all 
sorts of reasons, to use C++ as our primary development language.

Is there no outlook for QtWidgets to start using the GPU?

No, there is not. Not realisticly. First of all, widgets are "done", so 
not much development is going on there. But more important is that the 
way widgets are rendered simply doesn't suit the way modern GPU's work. 
It is the main reason Quick (2) was created in the first place: render 
the contents in such a way that it can utilize the GPU the way its meant 
to be used. That can't be retrofitted to the widgets world.


Note that even if you define your GUI in QML, you can still do 
everything else in C++. The QML doesn't have to be much more than what 
you already have as .ui files now, and they are not C++ either are they? 
Difference is of course that they get compiled into C++, where QML is not.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-05 Thread Scott Aron Bloom



-Original Message-
From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
Behalf Of Thiago Macieira
Sent: Tuesday, July 5, 2016 5:42 PM
To: interest@qt-project.org
Subject: Re: [Interest] Utilizing the GPU, how to start?

On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
> How does one get Qt widgets to take advantage of a GPU?  If this 
> question seem naïve, it is because it is.
> 
> With my application, I am displaying different types of media —
> mp4 (using QMedia Player)
> Html (folders containing a "mini-site” using QWebView) Images (using a 
> Qlabel)
> 
> This Qt 5.5, Windows7/10, running on a low end compute stick.  The CPU 
> seems to take the brunt of the performance.  Just wondering how to 
> offload some of that?

Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt 
Quick instead. Qt Quick uses the GPU, QtWidgets do not.
==

That’s a pretty horrible answer... There are MANY of us, who prefer for all 
sorts of reasons, to use C++ as our primary development language.

Is there no outlook for QtWidgets to start using the GPU?

Scott
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-05 Thread Thiago Macieira

On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
> How does one get Qt widgets to take advantage of a GPU?  If this question
> seem naïve, it is because it is.
> 
> With my application, I am displaying different types of media —
> mp4 (using QMedia Player)
> Html (folders containing a "mini-site” using QWebView)
> Images (using a Qlabel)
> 
> This Qt 5.5, Windows7/10, running on a low end compute stick.  The CPU seems
> to take the brunt of the performance.  Just wondering how to offload some
> of that?

Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt 
Quick instead. Qt Quick uses the GPU, QtWidgets do not.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Utilizing the GPU, how to start?

2016-07-05 Thread Jason Kretzer

How does one get Qt widgets to take advantage of a GPU?  If this question seem 
naïve, it is because it is.

With my application, I am displaying different types of media —
mp4 (using QMedia Player)
Html (folders containing a "mini-site” using QWebView)
Images (using a Qlabel)

This Qt 5.5, Windows7/10, running on a low end compute stick.  The CPU seems to 
take the brunt of the performance.  Just wondering how to offload some of that?

Thanks,

-Jason

//--//
   Jason R. Kretzer
   Lead Application Developer
   ja...@gocodigo.com
//--//

“quidquid latine dictum sit altum videtur"
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

40 matches

Mail list logo