[Interest] Utilizing the GPU, how to start?
mitch.curtis at qt.io
Tue Jul 12 08:38:48 CEST 2016
Have you tried Google? :D These two links probably cover your first two questions:
> -----Original Message-----
> From: Interest [mailto:interest-bounces+mitch.curtis=qt.io at qt-project.org]
> On Behalf Of John C. Turnbull
> Sent: Tuesday, 12 July 2016 4:06 AM
> To: Uwe Rathmann <Uwe.Rathmann at tigertal.de>
> Cc: interest at qt-project.org
> Subject: Re: [Interest] Utilizing the GPU, how to start?
> > On 10 Jul 2016, at 23:23, John C. Turnbull <ozemale at ozemail.com.au>
> > 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.Rathmann at tigertal.de>
> >>> 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 at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> Interest mailing list
> Interest at qt-project.org
More information about the Interest