[Interest] Few questions regarding Qt Quick Scene Graph

[Artem Fedoskin]

After evaluating the amount of xChanged(), yChanged() and visibleChanged()
signals I decided to stick with the approach where I create QQuickItems
from C++ with overriden updatePaintNode()  instead of direct instantiation
of QSGNodes. Thank you for your help! It was tremendous useful and now I
understand the internals of Scene Graph a little better.

Regards, Artem

2016-04-28 11:27 GMT+02:00 Gunnar Sletta <gunnar at sletta.org>:

>
> > On 27 Apr 2016, at 22:47, Artem Fedoskin <afedoskin3 at gmail.com> wrote:
> >
> > 1. I have experimented a little with the Scene Graph and got following
> results:
> >       • Rectangles with the same color were batched
> >       • Differently colored rectangles weren't batched
>
> Yeah, this is explained by the fact that QSGSimpleRectNode is implemented
> using the QSGFlatColorMaterial which passes the color via a uniform and
> will as a result have unique state per object. Prefer to use a
> QSGGeometryNode + QSGVertexColorMaterial instead as that allows you to use
> the same material state across all instances. You can even use the same
> material and save a tiny bit of memory in the process if that fits with
> your design.
>
> >       • Textures were batched if the QQuickWindow::TextureCanUseAtlas
> flag was set but only if QSG_ATLAS_WIDTH and QSG_ATLAS_HEIGHT were big
> enough.
>
> Sure, as is to be expected.
>
> > 2. I also found one of your E-mails here
> http://lists.qt-project.org/pipermail/interest/2014-January/010674.html
> where you suggested to use GL_MAX_TEXTURE_SIZE for setting atlas width and
> height, however, it didn't work when I set it as a value for environmental
> variable QSG_ATLAS_WIDTH and QSG_ATLAS_HEIGHT.
>
> Verify the atlas size using QSG_INFO=1 in the environment. Setting the
> environment variables does work, but we don't stuff textures into the atlas
> which will take up a huge percentage of it.
>
> > 3. If I'm going to create say 100 000 objects and change X and Y
> coordinates with setX() setY() funcitions and at the same time set some
> objects to invisible state with setVisible(), can signals emitted from
> calling this setters cause significant drop in performance if I'm not
> connecting any slots on my side?
>
> I would not use signals/slots for 100.000 lively changing objects.
>
> > 4. How setX() and setY() changes the position of the QQuickItem? I
> didn't noticed any calls to updatePaintNode() and is it better to set
> coordinates this way then directly changing coordinates of graphic nodes in
> updatePaintNode() and constantly call update()?
> >
>
> The geometry is changed, which triggers the transform node for that item
> to be changed. As the x/y does not change the contents, the paint node does
> not need to be updated and updatePaintNode() is not called.
>
> > Sorry for so much questions, but my project has to display and process a
> lot of items on the screen and it has to work good on mobile platforms.
>
> QML and SG apis are all well and nice, but did you consider doing parts of
> this visualization in raw OpenGL? Using for instance
> QQuickWindow::afterRendering() and doing a GL pass on top of the output
> frame allows you to batch and manage the GL resources explicitly. (Or
> beforeRendering and putting the UI on top as a HUD) The scene graph does a
> fairly good job at batching and will outperform trivial GL code in most
> cases, but for any given scenario, dedicated code will most likely
> outperform it.
>
> >
> > Thank you very much for all your advices and suggestions.
> >
> > Regards,
> >
> > Artem Fedoskin
> >
> >
> > 2016-04-26 9:19 GMT+02:00 Gunnar Sletta <gunnar at sletta.org>:
> >
> > > On 25 Apr 2016, at 19:46, Artem Fedoskin <afedoskin3 at gmail.com> wrote:
> > >
> > > Thank you for your reply Gunnar,
> > >
> > > Can you please tell me - can I store a pointer to the object of
> external class (even not a QQuickItem derived one) in QSGNode derived
> class? Each object of the class Data is associated with corresponding
> Triangle in View. Whenever View is updated, it checks in loop Data objects
> on special condition and based on that sets the corresponding Triangle to
> visible or invisible state. If Triangle is visible, Triangle itself calls a
> bunch of functions from external classes and uses pointer on object Data to
> retrieve Data's info about coordinates then accesses function from another
> class to convert the received coordinates to x,y positions.
> > >
> > > I understand that it is not safe to access QSGNode not from
> updatePaintNode(), but is it actually safe to access other classes from
> QSGNode itself? How far can I go in QSGNode in accessing things in GUI
> thread?
> >
> > Normal threading considerations apply. You can reference anything to
> your liking from objects that live on the render thread, there is nothing
> special about it. We just strongly encourage to not cross reference between
> GUI and render threads because the two run independently and objects can
> come and go on both.
> >
> > >
> > > Could you please also tell me - what is the way to hide QSGNode
> explicitly like for example setting QQuickItem::visible property to false.
> I found your E-Mail here
> http://lists.qt-project.org/pipermail/interest/2015-February/015285.html
> but I'm afraid that deallocating and allocating QSGNode will take
> unnecessary overhead as the visibility of nodes in my app will be often
> turned off/on. Is it a good idea to use QSGNode::removeChildNode() for this?
> >
> > You would have to have an opacity node in there then and set its opacity
> to 0. That way, they would still be in the scene graph (and still
> potentiallly consume processing and resources).
> >
> > Alternatively you could experiment with explicitly managing the node. If
> you during updatePaintNode stored the QSGNode that is passed in and return
> 0, you will effectively have taken ownership over that subtree from the SG.
> You could at a later time pass that stored node back to the SG. If there
> are GL resources associated with it, you will need to clean those up
> according to the section aboue "Graphics Resource Handling" in
> http://doc.qt.io/qt-5/qquickitem.html#custom-scene-graph-items.
> >
> > > How do you think - maybe instead of allocating directly QSGNodes I
> should just subclass instance of Data from QQuickItem and set its visual
> parent to View? Is allocating 1000 QSGNodes in View significantly faster
> than creating 1000 QQuickItems with the same painting logic and then
> setting its visual parent to View?
> >
> > Constructing a QSGNode in C++ is orders of magnitude faster than
> constructing a QQuickItem object through QML. Compared to a QQuickItem
> constructed in C++, I would still expect it to be faster, but probably not
> by a large margin.
> >
> > >
> > > Thank you
> > >
> > > Regards,
> > > Artem
> > >
> > > 2016-04-25 9:06 GMT+02:00 Gunnar Sletta <gunnar at sletta.org>:
> > >
> > > > On 24 Apr 2016, at 16:49, Artem Fedoskin <afedoskin3 at gmail.com>
> wrote:
> > > >
> > > > I'm sorry. My first E-Mail was sent accidentally. Here is the final
> version of my E-Mail.
> > > > Hello everybody. I have a project where a lot of objects are painted
> on the screen whenever the user interacts with the app (pan, zoom, move) I
> would be really grateful to you if you could answer a few questions
> regarding the internals of Qt Quick Scene Graph:
> > > >
> > > >       • Imagine that I add 1000 nodes with the same color inside
> QQuickItem::updatePaintNode() function of some QQuickItem derived class.
> Will they be drawn in batch as described in
> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html#batching
> ?
> > >
> > > Depends on the cirucmstances, but if they share clipping their
> QSGMaterial::compare() indicates they are all identical, they will be
> batched, yes. Verify with QSG_VISUALIZE=batches, as indicated by this same
> document.
> > >
> > > >       • Can I call the function of some other class in
> QQuickItem::updatePaintNode()? I have some class named Data, class named
> View and a subclass of QSGGeometryNode Triangle. Imagine that after objects
> of these classes are created the Data asks View to create 10 Triangles. The
> View creates 10 Triangles during the updatePaintNode() call and passes to
> them pointers to the object of class Data, that required their
> instantiation. The Triangles refers to the Data and get some values from it
> and converts them to x,y coordinates. Is it something possible?
> > > > Do I violate the rule stated here
> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering
> "Warning: It is crucial that OpenGL operations and interaction with the
> scene graph happens exclusively on the render thread, primarily during the
> updatePaintNode() call. The rule of thumb is to only use classes with the
> "QSG" prefix inside the QQuickItem::updatePaintNode() function." ?
> > >
> > > The point here is really that on many systems, there will be two
> threads that are running. The GUI thread where your QQuickItems live and
> the render thread where your QSGXxx objects live. updatePaintNode() is
> called on the render thread while the GUI thread is blocked, so you are
> safe to read state out of the QQuickItem at that time and use that to
> create/update/modify/delete your QSGXxx objects accordingly. At any other
> time, the two worlds live separate lives and should have no connection.
> > >
> > > There are other places where interaction between the threads are also
> ok, as outlined in the QQuickItem docs, but by sticking to the rule
> outlined in the updatePaintNode() function, 99% of all usecases will be
> covered.
> > >
> > > For your usecase you are free to construct View, Data, x number of
> Triangles during updatePaintNode() and then store that under some subclass
> of a QSGNode. On the next call,  you can update your structure if needed.
> Your QQuickItem does not store a pointer to this QSGNode, it only exists
> inside the scene graph and during the updatePaintNode() function.
> > >
> > > cheers,
> > > Gunnar
> > >
> > > >
> > > > At first I was thinking about deriving classes like Triangle from
> QQuickItem and then reparenting them to the View but the direct creation of
> QSGGeometryNodes seems to me to be less memory requiring approach.
> > > >
> > > > Regards,
> > > > Artem Fedoskin
> > > >
> > > > 2016-04-24 16:41 GMT+02:00 Artem Fedoskin <afedoskin3 at gmail.com>:
> > > > Hello everybody. I have a project where a lot of objects are painted
> on the screen whenever the user interacts with the app (pan, zoom, move) I
> would be really grateful to you if you could answer a few questions
> regarding the internals of Qt Quick Scene Graph:
> > > >
> > > >       • Imagine that I add 1000 nodes with the same color inside
> QQuickItem::updatePaintNode() function of some QQuickItem derived class.
> Will they be drawn in batch as described in
> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html#batching
> ?
> > > >       • Can I call the function of some other class in
> QQuickItem::updatePaintNode()? I have some class named Data, class named
> View and a subclass of QSGGeometryNode Triangle. Imagine that after objects
> of these classes are created the Data asks View to create 10 Triangles. The
> View creates 10 Triangles during the updatePaintNode() call and passes
> pointers to the object of class Data, that required their instantiation.
> The Triangles refers to the Data and get coordinates from it. Is it
> something possible. Do I violate the rule stated here "Warning: It is
> crucial that OpenGL operations and interaction with the scene graph happens
> exclusively on the render thread, primarily during the updatePaintNode()
> call. The rule of thumb is to only use classes with the "QSG" prefix inside
> the QQuickItem::updatePaintNode() function."
> > > >
> > > >
> > > >
> > > >       • For example, I want to get new coordinates of the object and
> to do that I should refer to function of some other not QSGNode derived
> object and then use these coordinates for rendering one of the nodes.
> > > >
> > > > _______________________________________________
> > > > Interest mailing list
> > > > Interest at qt-project.org
> > > > http://lists.qt-project.org/mailman/listinfo/interest
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160429/720bb0e2/attachment.html>