Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-29 Thread 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 :

>
> > On 27 Apr 2016, at 22:47, Artem Fedoskin  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 :
> >
> > > On 25 Apr 2016, at 19:46, Artem Fedoskin  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.
> >
> > >
> > > 

Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-28 Thread Gunnar Sletta

> On 27 Apr 2016, at 22:47, Artem Fedoskin  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 :
> 
> > On 25 Apr 2016, at 19:46, Artem Fedoskin  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?
> 

Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-27 Thread Artem Fedoskin
1. I have experimented a little with the Scene Graph and got following
results:

   1. Rectangles with the same color were batched
   2. Differently colored rectangles weren't batched
   3. Textures were batched if the QQuickWindow::TextureCanUseAtlas flag
   was set but only if QSG_ATLAS_WIDTH and QSG_ATLAS_HEIGHT were big enough.

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.

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?

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()?

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.

Thank you very much for all your advices and suggestions.

Regards,

Artem Fedoskin

2016-04-26 9:19 GMT+02:00 Gunnar Sletta :

>
> > On 25 Apr 2016, at 19:46, Artem Fedoskin  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 :
> >
> > > On 24 Apr 2016, at 16:49, Artem Fedoskin  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 

Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-26 Thread Gunnar Sletta

> On 25 Apr 2016, at 19:46, Artem Fedoskin  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 :
> 
> > On 24 Apr 2016, at 16:49, Artem Fedoskin  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, 

Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-25 Thread Artem Fedoskin
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?

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?

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?

Thank you

Regards,
Artem

2016-04-25 9:06 GMT+02:00 Gunnar Sletta :

>
> > On 24 Apr 2016, at 16:49, Artem Fedoskin  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 

Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-25 Thread Gunnar Sletta

> On 24 Apr 2016, at 16:49, Artem Fedoskin  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 :
> 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 

Re: [Interest] Few questions regarding Qt Quick Scene Graph

2016-04-24 Thread Artem Fedoskin
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:

   1. 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
   

   ?
   2. 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." ?

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 :

> 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:
>
>1. 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
>
> 
>?
>2. 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."
>3.
>4.
>5.
>6. 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