[Development] QSceneGraph debugging

[Thomas Senyk]

Hi,

currently trying to debug a weird behavior on a TI chip (armv7 with a 
SGX GPU).


I have a fairly simple QML with a simple GridView with model:200 and 
delegate:Text{text: "T#"+index}.
(it's a tiny bit more then that, but for argument sake this should be 
enough)

Then an animation scrolling up and down (on "contentY", without items 
leaving the screen to avoid item creation in performance debugging).

So far so good .. plain 60fps, all frames ~16ms

But when I do
          color:  Qt.rgba(Math.random(), 1, 1,1);   [4]
on the Text-delegate, then I get very bad performance (<20fps).

Looking closer at the frame times it's good performance for a couple of 
frames (~16ms) and then one terrible frame with >200ms.

That in mind I dug further .. and found that it's:
In every "bad" frame
Updater::visitGeometryNode [1]
this is called with m_added==1

And this causes (because e->root==0 [2])
renderer->m_rebuild |= Renderer::FullRebuild;

Then nearly all the frame time (>200ms) is spend uploading the new 
batches in Renderer::uploadBatch [3]


Comparing all that with the "black"-case I see:
  - Batch  0 0x281f58 upload  root: 0x1a4a58
    - element: 0x27ad18 Rect( -0.833333 0.576389 27.4661 13.5365 ) 
node: GeometryNode( 0x27ab30 triangles #V: 12 #I: 18 x1= -0.833333 y1= 
0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6fad3c4 )  order: 1
    - element: 0x279ca0 Rect( 79.1667 0.732639 107.666 13.3889 )  node: 
GeometryNode( 0x279ab8 triangles #V: 12 #I: 18 x1= -0.833333 y1= 
0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6fad3c4 )  order: 2
    - element: 0x278c28 Rect( 159.167 0.576389 187.327 13.3889 )  node: 
GeometryNode( 0x278a40 triangles #V: 12 #I: 18 x1= -0.833333 y1= 
0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6fad3c4 )  order: 3

...all in one Batch.

For color:
  - Batch  0 0x2845f8 upload  root: 0x16bd58
    - element: 0x283a20 Rect( -0.833333 0.576389 27.4661 13.5365 ) 
node: GeometryNode( 0x283838 triangles #V: 12 #I: 18 x1= -0.833333 y1= 
0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6f583c4 )  order: 1
  - Batch  1 0x1702c8 upload  root: 0x16bd58
    - element: 0x2829a8 Rect( 79.1667 0.732639 107.666 13.3889 )  node: 
GeometryNode( 0x2827c0 triangles #V: 12 #I: 18 x1= -0.833333 y1= 
0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6f583c4 )  order: 2
  - Batch  2 0x2853a0 upload  root: 0x16bd58
    - element: 0x281930 Rect( 159.167 0.576389 187.327 13.3889 )  node: 
GeometryNode( 0x281748 triangles #V: 12 #I: 18 x1= -0.833333 y1= 
0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6f583c4 )  order: 3

... one node one batch [4].

So batching can't work on differently colored elements/text/..?
     ... is color a uniform per draw call?



 From the past I know that my test-case had good performance on older 
SoCs .. so the question I have right now are:

[1]: There shouldn't be a new Node .. nothing new is created?

[2]: Should one simple node cause all batches to be re-uploaded?
        .. or better: why do I get Renderer::FullRebuild?

[3]: If all above is normal, then maybe it's the data upload that's to 
long? glBufferData in unmap is 300-400us on average (with ~200 of them 
in each "bad" frame) .. is that "normal"? sounds rather long for a 
couple of vertices (if it's only a couple of vertices?)

[4]: And again: I guess batching on non color-sharing elements is 
supposed to not work?



Greets
Thomas