Tasharen Entertainment Forum
Support => NGUI 3 Support => Topic started by: Eskema on October 03, 2014, 06:50:26 AM
-
Hi,
After reading all the other posts about scrollview I can tell that I have no idea what's going on, using version 3.7.4
I'm working on iOS, I have a normal setup, panel, within the panel the other panel with a scrollview
-panel
--some widgets
--panel with scrollview
---uigrid
----background with 2 more widgets
Well, I have 1 item in my grid, a background acting as my container with a button and a label, nothing fancy. The scrollview clip area is 1005x600 and the screen resolution is 1024x768
As you can see in the images, prior to show the scrollview (which is hidden until you press a button)
(https://dl.dropboxusercontent.com/u/4559064/issue_ngui/prior_scrollview.png)
The performance is acceptable, 30% seems fine.
After hitting the button the scrollview kicks in
(https://dl.dropboxusercontent.com/u/4559064/issue_ngui/showing_emptyscrollview.png)
The cpu skyrockets to an 80% which makes no sense to me, after all I have only 1 item, in total 3 widgets within the scrollview.
And finally here's the image showing you the scrollview itself
(https://dl.dropboxusercontent.com/u/4559064/issue_ngui/scrollview.jpg)
The central area with that squared image is the scrollview, and within that I have the background, the button and the label, nothing else, no draggable panels, no animations, nothing at all, just what you see on the image, all completely static.
Things that I've tried:
- remove the panel and the scroll, obviously no scroll at all, BUT still just by showing those 3 widgets the cpu goes up to 40% which makes no sense to have 3 widgets on top covering the area, but well, I don't care.
-Another thing I've tried is to reduce the clip area, instead of 1005x600 I've reduced the area to 200x600, still no luck, the cpu goes up, not 80% but 70%, which makes the scrollview completely unusable.
-And finally I had the same setup as the test scene (number 7), with the same issues, so I didn't placed anything wrong, just in case....
Any ideas?
-
Well, what does the profiler window say? Where is the time spent?
-
this is a shot of the profiler with the deep profile activated, I have to say that in this case I've added the rest of content to the scroll view, which means 3 labels with some text (around 140 characters each label) plus what you saw on the previous screenshots
(https://dl.dropboxusercontent.com/u/4559064/issue_ngui/profiler.png)
Most of the time goes as expected on the lateupdate, and when you scroll the memory wastage goes up sometimes even to 400ks, like this screenshot, and this will trigger our garbage collector in no time.
(https://dl.dropboxusercontent.com/u/4559064/issue_ngui/profiler_with_scroll.png)
In case you ask, the answer is no, I have only 1 script doing a start call to fill the labels I have within the scroll, but no other scripts doing anything at all, no updates. As a general rule I saw a drop in performance of about a 10% each time you use a scrollview (according to ios profiler, I don't care about the unity profiler in this case because I'm looking for fps values), and the more content the scrollview has, the more time needed to draw (normal stuff I would say), but seems pretty expensive in general the scrollview
-
First, don't use deep profiling. It doesn't give accurate performance analysis. I've explained this many times before, and Unity's documentation says the same thing.
When you start a panel dragging operation, if you don't have culling enabled on the panel it means that all widgets suddenly become visible, meaning they all get dumped into one large draw call. As you drag it around, it won't need to be re-created though. If culling is enabled, the draw buffer will change when some widget becomes visible or goes outside the panel's view. Either way the scrolling causes buffers to be rebuilt at some point.
-
I usually don't use the deep profile, but in this case I wanted to know more about the low performance. Anyways, I've tried with both cull and no cull option and it's the same (no performance gain at all), the static option, etc.
I will keep digging :)
-
@ArenMook
I'm new here, don't know how to post a topic exactly, but it has to do with the Scrollview Performance.
1 )When I run my Level Select Scrollview after the app has opened on my iPhone5, I get a smooth 60fps and a smooth scrollview, however....
When I navigate to Level 1 and then navigate back to my Level Select Menu, I retain a smooth 60fps, however the scrollview is now not nearly as smooth even with 60fps.
What could be the cause of this? It seems rather odd that it works perfectly smooth and then after navigating away it's glitchy/not so smooth.
2) (On a side note, , is it also possible to get that lag position effect on a scrollview? or something that is 2D related)
Thanks in advance
-
I don't understand #2.
Regarding #1: If it was 60 fps before, and it remains 60 fps, then nothing should alter the feel of the scroll view.