[Interest] Utilizing the GPU, how to start?
John C. Turnbull
ozemale at ozemail.com.au
Sun Jul 10 15:23:18 CEST 2016
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.
> 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.
> Interest mailing list
> Interest at qt-project.org
More information about the Interest