Question on IOS Draggable Panel Optimization

[blitzer]

Hello everyone, I tested out my ngui setup for a draggable panel today, and got some some pretty sub-par results. I'm sure the problem is me (not knowing what to look for), and was wondering if I could get some feedback on what is causing the performance problems. Below, is a readout of stats from the game (while it was in Unity and XCode) as well as a screenshot so you can get an idea of what I'm going for:

Notes:
- This is on a iPhone 4
- all atlases and atlas materials are unlit/transparent colored and no larger than 2048x2048
- when switching to this screen on the iPhone, I can actually see these images being loaded in according to their depth (so background, then image, then image frames, etc).

Stats:
Xcode general stats:   cpu   memory   fps         
                          23%   28.4mb   22         
                  
xcode opengl es stats:   utilization (tiler)   utilization (renderer)      frametime (cpu)   frame time (GPU)   
                               3%                100%                        7.5ms                45ms   
                  
unity internal profiler stats:   cpu player   cpu ogles-drv   cpu-present   cpu-waits-gpu   frametime   update
                                      6.31              0.9                  37.6                  37.6                 45       3.2
                  
unity editor stats:   draw calls   used textures   Vram                   VBO total      
                               10              4-46mb              1.9 to 46.6mb   23-106KB      

Any ideas are appreciated.

[ArenMook]

You're severely GPU-limited here, meaning you are limited not by NGUI but what you're drawing.

Try reducing overdraw (widgets drawn on top of other widgets). The less stuff you have overlapping the better the performance. It also seems that you have many panels in there... which implies many draw calls. Reducing draw calls is extremely important on a mobile device. Your UI should be less than 10 draw calls at its absolute peak.

[blitzer]

As per your suggestion, I re-did the ui setup with 2 panels instead of 4, which more/less doubled the FPS and cut the cpu time in half when the panel is moving. Two follow ups though:

1) Because I'm now only using 2 panels, the level boxes now render on top of the "frame" (the wood texture defining the box area). Since I can't use another panel to move the frame into a higher layer and because putting the frame on the panel that moves causes it to jitter when the panel moves, how can I make sure that the Frame renders on top of the level boxes?

- I've tried putting both panels onto the same layer and changing the layer order, but that didn't seem to work.

-And I've considered changing the parenting offset on the 2nd panel, but it still leaves room for error.

2) I'm still seeing the strange issue where when the screen is switched, I can see levels 1 and 3 load their images in order (and I'm even seeing this occur in the regular menu buttons as well), level 2 (and all other levels) don't seem to have this issue.

Any ideas are appreciated.

[ArenMook]

Adjust the depth. All widgets have it, and it's what controls what's in front of what. Panels have depth controls the draw order between panels. Widget depth controls the draw order between widgets.

All panels collect their widgets sorted by widget depth, creating draw calls. Draw calls themselves are sorted by panel depth.

Knowing nothing about how you create your UI or how you load things, I can't comment much on what's happening.

[blitzer]

Adjust the depth. All widgets have it, and it's what controls what's in front of what.
--That's what I'm getting at, the wood frame has a higher depth than any of the level box components, but the boxes are still being drawn on top of the frame - that was what was confusing me since both panels have the same depth.

[ArenMook]

Panels having the same depth doesn't mean that they will share the draw calls.

New panel = new set of draw calls, regardless of depth.

If you have a background widget, scroll view on top, and still want something on top of the scroll view, that requires 3 panels.

[blitzer]

Ok, that was the conclusion that I had come to, thank you for the clarification.