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
