[Interest] Utilizing the GPU, how to start?

John C. Turnbull ozemale at ozemail.com.au
Tue Jul 12 04:06:08 CEST 2016


Anyone? 

> On 10 Jul 2016, at 23:23, John C. Turnbull <ozemale at 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.Rathmann at 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 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




More information about the Interest mailing list