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 <gun...@sletta.org>: > > > On 27 Apr 2016, at 22:47, Artem Fedoskin <afedosk...@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 <gun...@sletta.org>: > > > > > On 25 Apr 2016, at 19:46, Artem Fedoskin <afedosk...@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 <gun...@sletta.org>: > > > > > > > On 24 Apr 2016, at 16:49, Artem Fedoskin <afedosk...@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 <afedosk...@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@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