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