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
