Discussion:
Utilizing the GPU, how to start?
(too old to reply)
Jason Kretzer
2016-07-05 18:45:41 UTC
Permalink
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
***@gocodigo.com<mailto:***@gocodigo.com>
//------------------------------//

“quidquid latine dictum sit altum videtur"
Thiago Macieira
2016-07-06 00:41:33 UTC
Permalink
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
Scott Aron Bloom
2016-07-06 00:56:04 UTC
Permalink
-----Original Message-----
From: Interest [mailto:interest-bounces+scott=***@qt-project.org] On Behalf Of Thiago Macieira
Sent: Tuesday, July 5, 2016 5:42 PM
To: ***@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
André Somers
2016-07-06 06:34:44 UTC
Permalink
Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:
>
> -----Original Message-----
> From: Interest [mailto:interest-bounces+scott=***@qt-project.org] On Behalf Of Thiago Macieira
> Sent: Tuesday, July 5, 2016 5:42 PM
> To: ***@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é
Shawn Rutledge
2016-07-06 07:24:14 UTC
Permalink
> On 6 Jul 2016, at 08:34, André Somers <***@familiesomers.nl> wrote:
>
> Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:
>>
>> -----Original Message-----
>> From: Interest [mailto:interest-bounces+scott=***@qt-project.org] On Behalf Of Thiago Macieira
>> Sent: Tuesday, July 5, 2016 5:42 PM
>> To: ***@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.
Kai Koehne
2016-07-06 07:53:28 UTC
Permalink
> -----Original Message-----
> From: Interest [mailto:interest-bounces+kai.koehne=***@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
John C. Turnbull
2016-07-06 08:30:44 UTC
Permalink
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 <***@qt.io> wrote:
>
>
>
>> -----Original Message-----
>> From: Interest [mailto:interest-bounces+kai.koehne=***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
Dmitry Volosnykh
2016-07-06 08:33:06 UTC
Permalink
John, here you are: https://blog.qt.io/?s=vulkan&lang=en

On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull <***@ozemail.com.au>
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 <***@qt.io> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: Interest [mailto:interest-bounces+kai.koehne=***@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
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
John C. Turnbull
2016-07-06 09:41:52 UTC
Permalink
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 <***@gmail.com> wrote:
>
> John, here you are: https://blog.qt.io/?s=vulkan&lang=en
>
>> On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull <***@ozemail.com.au> 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 <***@qt.io> wrote:
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Interest [mailto:interest-bounces+kai.koehne=***@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
>> > ***@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/interest
>>
>> _______________________________________________
>> Interest mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
Giuseppe D'Angelo
2016-07-06 10:10:04 UTC
Permalink
On Wed, Jul 6, 2016 at 11:41 AM, John C. Turnbull
<***@ozemail.com.au> 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
Sean Harmer
2016-07-06 10:26:07 UTC
Permalink
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 <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
>> John, here you are: https://blog.qt.io/?s=vulkan&lang=en
>>
>> On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull
>> <***@ozemail.com.au <mailto:***@ozemail.com.au>> 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 <***@qt.io
>> <mailto:***@qt.io>> wrote:
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Interest [mailto:interest-bounces+kai.koehne
>> <mailto:interest-bounces%2Bkai.koehne>=***@qt-project.org
>> <mailto:***@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
>> > ***@qt-project.org <mailto:***@qt-project.org>
>> > http://lists.qt-project.org/mailman/listinfo/interest
>>
>> _______________________________________________
>> Interest mailing list
>> ***@qt-project.org <mailto:***@qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
John C. Turnbull
2016-07-06 11:27:12 UTC
Permalink
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 <***@kdab.com> 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 <***@gmail.com> wrote:
>>
>>> John, here you are: https://blog.qt.io/?s=vulkan&lang=en
>>>
>>>> On Wed, Jul 6, 2016 at 11:31 AM John C. Turnbull <***@ozemail.com.au> 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 <***@qt.io> wrote:
>>>> >
>>>> >
>>>> >
>>>> >> -----Original Message-----
>>>> >> From: Interest [mailto:interest-bounces+kai.koehne=***@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
>>>> > ***@qt-project.org
>>>> > http://lists.qt-project.org/mailman/listinfo/interest
>>>>
>>>> _______________________________________________
>>>> Interest mailing list
>>>> ***@qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>> _______________________________________________
>> Interest mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
Henry Skoglund
2016-07-06 15:53:07 UTC
Permalink
Hi, got an HTC Vive last week, it was really for my son but I've tried
it as well, I haven't enjoyed a shooter game this much since playing
Apple Invaders on my Apple II.

Anyway, I've downloaded the OpenVR SDK from Valve
https://github.com/ValveSoftware/openvr, I want to try displaying some
math graphs in 3D in the helmet, and perhaps try building and walking in
a maze.

Of course I'll be writing my test program in Qt, figure Qt 3D would be
swell for this. Are there any plans or ideas for VR using Qt 3D?

Regards Henry
Sean Harmer
2016-07-06 16:26:23 UTC
Permalink
Hey!

I just had my first play with the Vive today too. Peppe is already
looking into the SDK so that we can first get some pure Qt + OpenGL
examples working with it. Once we've gained a little experience with it
we will look at how to expose this to Qt 3D's API.

Cheers,

Sean

On 06/07/2016 16:53, Henry Skoglund wrote:
> Hi, got an HTC Vive last week, it was really for my son but I've tried
> it as well, I haven't enjoyed a shooter game this much since playing
> Apple Invaders on my Apple II.
>
> Anyway, I've downloaded the OpenVR SDK from Valve
> https://github.com/ValveSoftware/openvr, I want to try displaying some
> math graphs in 3D in the helmet, and perhaps try building and walking
> in a maze.
>
> Of course I'll be writing my test program in Qt, figure Qt 3D would be
> swell for this. Are there any plans or ideas for VR using Qt 3D?
>
> Regards Henry
>
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
Henry Skoglund
2016-07-06 16:47:10 UTC
Permalink
Excellent! I'm quite the noob re. Qt 3D, but this VR stuff could be a
nice educational entry into it.

(When you sit in front on the computer inside Qt Creator all day, it's
refreshing to stand up, put on the Vive and shoot some aliens :-)

Rgrds Henry


On 2016-07-06 18:26, Sean Harmer wrote:
> Hey!
>
> I just had my first play with the Vive today too. Peppe is already
> looking into the SDK so that we can first get some pure Qt + OpenGL
> examples working with it. Once we've gained a little experience with it
> we will look at how to expose this to Qt 3D's API.
>
> Cheers,
>
> Sean
>
> On 06/07/2016 16:53, Henry Skoglund wrote:
>> Hi, got an HTC Vive last week, it was really for my son but I've tried
>> it as well, I haven't enjoyed a shooter game this much since playing
>> Apple Invaders on my Apple II.
>>
>> Anyway, I've downloaded the OpenVR SDK from Valve
>> https://github.com/ValveSoftware/openvr, I want to try displaying some
>> math graphs in 3D in the helmet, and perhaps try building and walking
>> in a maze.
>>
>> Of course I'll be writing my test program in Qt, figure Qt 3D would be
>> swell for this. Are there any plans or ideas for VR using Qt 3D?
>>
>> Regards Henry
>>
>>
>> _______________________________________________
>> Interest mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
charleyb123 .
2016-07-06 16:52:27 UTC
Permalink
On Wed, Jul 6, 2016 at 10:47 AM, Henry Skoglund <***@tungware.se> wrote:

> Excellent! I'm quite the noob re. Qt 3D, but this VR stuff could be a nice
> educational entry into it.
>
> (When you sit in front on the computer inside Qt Creator all day, it's
> refreshing to stand up, put on the Vive and shoot some aliens :-)
>
> Rgrds Henry
>

+1 on the Qt3D+VR SDK.

A gentle note of caution ... not all of the aliens should be considered
targets. ;-)

--charley
André Somers
2016-07-07 06:07:41 UTC
Permalink
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é
Thiago Macieira
2016-07-06 06:58:48 UTC
Permalink
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
Uwe Rathmann
2016-07-06 17:40:47 UTC
Permalink
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
J-P Nurmi
2016-07-06 18:10:37 UTC
Permalink
> On 06 Jul 2016, at 19:41, Uwe Rathmann <***@tigertal.de> 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
André Pönitz
2016-07-06 19:04:13 UTC
Permalink
On Wed, Jul 06, 2016 at 06:10:37PM +0000, J-P Nurmi wrote:
> > On 06 Jul 2016, at 19:41, Uwe Rathmann <***@tigertal.de>
> > 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'
Uwe Rathmann
2016-07-07 06:47:35 UTC
Permalink
On Wed, 06 Jul 2016 18:10:37 +0000, 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
Sean Harmer
2016-07-07 18:11:37 UTC
Permalink
Hi,

On 07/07/2016 07:47, Uwe Rathmann wrote:
> On Wed, 06 Jul 2016 18:10:37 +0000, 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>

--
Dr Sean Harmer | ***@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
Uwe Rathmann
2016-07-08 07:01:16 UTC
Permalink
Hi Sean,

> So what were the results of profiling? CPU usage caused by
> animations/batching, something else? GPU? Bandwidth? Lock contention?

The first time we reported the issue was 2014: https://bugreports.qt.io/
browse/QTBUG-43096. At that time we had to migrate back to Qt 5.1.

When Qt 5.6 came out we made an analysis comparing Qt 5.1 with 5.6. I
would like to publish it, but as I didn't do it myself ( AFAIK it was
done by someone having a background in the development of the 5.1
JavaScript engine ) I can't decide on that.

But in short: it shows, that Qt 5.6 is much better than 5.3, but still
behind 5.1. So at some point we will be able to migrate, but of course
this won't solve problems, that already exist in 5.1.

( The performance of the rendering is significantly better with Qt 5.6,
but as we never had a problem with rendering. )

> Any test cases to help others profile it?

Just to give you a silly number: every push button of Controls 1 is made
of 30 QObjects - every stop of a gradient adds an additional object.

I recommend to do the exercise of counting the number of QObjects below
the QQuickWindow of an application to everyone. Considering QObject being
something "heavy" ( QQuickItem even "heavier" ), the numbers are just
terrifying.

This issue will be part of Andrews presentation ( https://conf.qtcon.org/
en/qtcon/public/events/428 ).

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

Sure, but does this affect application code dealing with how to configure
and lay out controls on a page and what to do, when f.e. a button gets
pressed ?

Uwe
Giuseppe D'Angelo
2016-07-08 09:19:14 UTC
Permalink
On 08/07/16 08:01, Uwe Rathmann wrote:
> Just to give you a silly number: every push button of Controls 1 is made
> of 30 QObjects - every stop of a gradient adds an additional object.
>
> I recommend to do the exercise of counting the number of QObjects below
> the QQuickWindow of an application to everyone. Considering QObject being
> something "heavy" ( QQuickItem even "heavier" ), the numbers are just
> terrifying.
>
> This issue will be part of Andrews presentation (https://conf.qtcon.org/
> en/qtcon/public/events/428 ).
>

I think the question was more about measuring CPU and GPU performance
than memory. Do you happen to have those numbers?

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

Cheers,
--
Giuseppe D'Angelo | ***@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
Uwe Rathmann
2016-07-08 11:02:05 UTC
Permalink
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
Giuseppe D'Angelo
2016-07-08 16:51:47 UTC
Permalink
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 | ***@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
Uwe Rathmann
2016-07-10 12:24:20 UTC
Permalink
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
John C. Turnbull
2016-07-10 13:23:18 UTC
Permalink
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 <***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
John C. Turnbull
2016-07-12 02:06:08 UTC
Permalink
Anyone?

> On 10 Jul 2016, at 23:23, John C. Turnbull <***@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 <***@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
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
Mitch Curtis
2016-07-12 06:38:48 UTC
Permalink
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-project.org]
> On Behalf Of John C. Turnbull
> Sent: Tuesday, 12 July 2016 4:06 AM
> To: Uwe Rathmann <***@tigertal.de>
> Cc: ***@qt-project.org
> Subject: Re: [Interest] Utilizing the GPU, how to start?
>
> Anyone?
>
> > On 10 Jul 2016, at 23:23, John C. Turnbull <***@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 <***@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
> >> ***@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> >
> > _______________________________________________
> > Interest mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
John C. Turnbull
2016-07-12 06:53:25 UTC
Permalink
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 <***@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-project.org]
>> On Behalf Of John C. Turnbull
>> Sent: Tuesday, 12 July 2016 4:06 AM
>> To: Uwe Rathmann <***@tigertal.de>
>> Cc: ***@qt-project.org
>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>
>> Anyone?
>>
>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <***@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
alexander golks
2016-07-12 07:01:27 UTC
Permalink
Am Tue, 12 Jul 2016 16:53:25 +1000
schrieb "John C. Turnbull" <***@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 <***@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-project.org]
> >> On Behalf Of John C. Turnbull
> >> Sent: Tuesday, 12 July 2016 4:06 AM
> >> To: Uwe Rathmann <***@tigertal.de>
> >> Cc: ***@qt-project.org
> >> Subject: Re: [Interest] Utilizing the GPU, how to start?
> >>
> >> Anyone?
> >>
> >>>> On 10 Jul 2016, at 23:23, John C. Turnbull <***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


--
John C. Turnbull
2016-07-12 07:04:48 UTC
Permalink
It's OK - they "do no evil" ;-)

> On 12 Jul 2016, at 17:01, alexander golks <***@golks.de> wrote:
>
> Am Tue, 12 Jul 2016 16:53:25 +1000
> schrieb "John C. Turnbull" <***@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 <***@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-project.org]
>>>> On Behalf Of John C. Turnbull
>>>> Sent: Tuesday, 12 July 2016 4:06 AM
>>>> To: Uwe Rathmann <***@tigertal.de>
>>>> Cc: ***@qt-project.org
>>>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>>>
>>>> Anyone?
>>>>
>>>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <***@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
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
> --
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
Sze Howe Koh
2016-07-12 09:41:10 UTC
Permalink
On 12 July 2016 at 14:53, John C. Turnbull <***@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 <***@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-project.org]
>>> On Behalf Of John C. Turnbull
>>> Sent: Tuesday, 12 July 2016 4:06 AM
>>> To: Uwe Rathmann <***@tigertal.de>
>>> Cc: ***@qt-project.org
>>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>>
>>> Anyone?
>>>
>>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <***@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
John C. Turnbull
2016-07-12 11:26:20 UTC
Permalink
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 <***@gmail.com> wrote:
>
>> On 12 July 2016 at 14:53, John C. Turnbull <***@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 <***@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-project.org]
>>>> On Behalf Of John C. Turnbull
>>>> Sent: Tuesday, 12 July 2016 4:06 AM
>>>> To: Uwe Rathmann <***@tigertal.de>
>>>> Cc: ***@qt-project.org
>>>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>>>>
>>>> Anyone?
>>>>
>>>>>> On 10 Jul 2016, at 23:23, John C. Turnbull <***@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
Till Oliver Knoll
2016-07-12 18:04:35 UTC
Permalink
> Am 12.07.2016 um 11:41 schrieb Sze Howe Koh <***@gmail.com>:
>

> .... Note that it is currently summer holidays in Norway, so
> most of the staff are on leave till the end of July.

They have summer in Norway?

*duck and cover*

;)

Cheers,
Oliver

P.S. At least "our" summer in Switzerland is terribly letting us down again currently.
Thiago Macieira
2016-07-12 19:50:16 UTC
Permalink
Em terça-feira, 12 de julho de 2016, às 20:04:35 PDT, Till Oliver Knoll
escreveu:
> > Am 12.07.2016 um 11:41 schrieb Sze Howe Koh <***@gmail.com>:
> >
> >
> > .... Note that it is currently summer holidays in Norway, so
> > most of the staff are on leave till the end of July.
>
> They have summer in Norway?
>
> *duck and cover*

Sure. It lasts a week or two only; it's probably over by now, though.

The rest is the "green Winter".

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
BAILLY Yves
2016-07-06 07:54:44 UTC
Permalink
> -----Original Message-----
> From: Interest [mailto:interest-bounces+yves.bailly=***@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Wednesday, July 06, 2016 8:59 AM
> To: ***@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
Thiago Macieira
2016-07-13 06:29:56 UTC
Permalink
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
André Pönitz
2016-07-06 18:23:44 UTC
Permalink
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'
Scott Aron Bloom
2016-07-06 18:27:45 UTC
Permalink
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
Thiago Macieira
2016-07-06 21:16:46 UTC
Permalink
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
André Pönitz
2016-07-06 23:03:23 UTC
Permalink
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'
Thiago Macieira
2016-07-06 23:30:15 UTC
Permalink
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
Jason H
2016-07-06 16:19:48 UTC
Permalink
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Giuseppe D'Angelo
2016-07-08 17:11:06 UTC
Permalink
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 | ***@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
Jason H
2016-07-08 19:23:34 UTC
Permalink
> Sent: Friday, July 08, 2016 at 1:11 PM
> From: "Giuseppe D'Angelo" <***@kdab.com>
> To: ***@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.
Continue reading on narkive:
Loading...