1
NGUI 3 Support / Re: Scroll view manic behavior before first touch
« on: February 26, 2014, 06:21:28 AM »
Thanks, yes indeed some of our less experienced team members put anchors on the scroll panels. <sigh>
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
NGUI 3 Support / Scroll view manic behavior before first touch
« on: February 25, 2014, 11:31:20 AM »
Hi,
As of 3.5.1, our scroll views display odd behavior. When first loaded, the offset and center values of the scroll panels appear to rise / fall uncontrollably as frames go by. This results in no visible movement of the scroll view, but if left alone the values continue to rise indefinitely which must be bad! Moreover, in some of our views, this behavior appears to make the scroll view "lock up" and refuse to budge when dragged (in-editor & on-device). Specifically, the drag is instantly cancelled in the next frame, and the scroll view is pulled back to its origin.
Perhaps related, we are also seeing an occasional ability to drag a scroll view initially (once) even if it is entirely within the frame bounds despite the "Cancel Drag If Fits" box being checked.
Upon further investigation, we have discovered that commenting out line 551 "mPanel.clipOffset = new Vector2(clip.x - cr.x, clip.y - cr.y);" in UIScrollView prevents the problem. We are not sure what further consequences may result, however, so we are wary of simply adopting this change without your recommendation.
Thanks,
Nicholas Bellerophon
Senior Developer
p.s. thanks for the mesh memory leak fix, our application now profiles clean and memory-stable; we are able to proceed with our next release and greatly appreciate your efforts to keep NGUI the best middle-ware in the asset store
As of 3.5.1, our scroll views display odd behavior. When first loaded, the offset and center values of the scroll panels appear to rise / fall uncontrollably as frames go by. This results in no visible movement of the scroll view, but if left alone the values continue to rise indefinitely which must be bad! Moreover, in some of our views, this behavior appears to make the scroll view "lock up" and refuse to budge when dragged (in-editor & on-device). Specifically, the drag is instantly cancelled in the next frame, and the scroll view is pulled back to its origin.
Perhaps related, we are also seeing an occasional ability to drag a scroll view initially (once) even if it is entirely within the frame bounds despite the "Cancel Drag If Fits" box being checked.
Upon further investigation, we have discovered that commenting out line 551 "mPanel.clipOffset = new Vector2(clip.x - cr.x, clip.y - cr.y);" in UIScrollView prevents the problem. We are not sure what further consequences may result, however, so we are wary of simply adopting this change without your recommendation.
Thanks,
Nicholas Bellerophon
Senior Developer
p.s. thanks for the mesh memory leak fix, our application now profiles clean and memory-stable; we are able to proceed with our next release and greatly appreciate your efforts to keep NGUI the best middle-ware in the asset store
3
NGUI 3 Support / Re: Long length UILabel memory usage
« on: February 21, 2014, 09:17:57 AM »
Hi,
We're also experiencing memory crashes on mobile due to using extremely long UILabels (for Ts&Cs, Privacy Policy, FAQ, etc.).
Profiling, we find the memory leak is in the Not Saved - Mesh category as noted above. I call it a leak because we have found no way to clear this memory once it increases, even after the user navigates away from the screen and we:
Destroy ( view ); delay 1 frame; Resources.UnloadUnusedAssets (); GC.Collect ();
I tried adding UIDrawCall.ClearAll () and UIDrawCall.ReleaseAll (), but those don't appear to release the memory either. Rather they appear to make the situation slightly worse.
So our primary questions are: how do we release this memory? How to we kill the meshes?
Our secondary question is: does a long UILabel really have to cause a 35MB mesh memory spike?
Additional notes: looking at the profiler, we actually see several entries under the mesh category, but apparently using the same texture and font. Each entry is taking its own memory, and contributing towards the category total. Individuals entries range in size from 300k to 6Mb at peak. Most go up together, but some sit lower for awhile as others rise. None of the entries ever goes down in size or gets removed.
To repro this, just put a few UILabels in a scrollview, then dynamically fill the text in via code at runtime. They text should be very long, say about 20 mobile screens worth. Split that amount across the labels if using a single label fails to display or causes a crash. We test with iPod touches since their memory characteristics are relatively weak. Get device and editor on same Wifi and autoconnect profiler to see (hopefully) what we see in the profiler. Profiler in-editor produces strange results and we question their accuracy / relevance.
Many thanks, let us know if you would like further details.
Nicholas Bellerophon
Senior Developer
Yummi Media
We're also experiencing memory crashes on mobile due to using extremely long UILabels (for Ts&Cs, Privacy Policy, FAQ, etc.).
Profiling, we find the memory leak is in the Not Saved - Mesh category as noted above. I call it a leak because we have found no way to clear this memory once it increases, even after the user navigates away from the screen and we:
Destroy ( view ); delay 1 frame; Resources.UnloadUnusedAssets (); GC.Collect ();
I tried adding UIDrawCall.ClearAll () and UIDrawCall.ReleaseAll (), but those don't appear to release the memory either. Rather they appear to make the situation slightly worse.
So our primary questions are: how do we release this memory? How to we kill the meshes?
Our secondary question is: does a long UILabel really have to cause a 35MB mesh memory spike?
Additional notes: looking at the profiler, we actually see several entries under the mesh category, but apparently using the same texture and font. Each entry is taking its own memory, and contributing towards the category total. Individuals entries range in size from 300k to 6Mb at peak. Most go up together, but some sit lower for awhile as others rise. None of the entries ever goes down in size or gets removed.
To repro this, just put a few UILabels in a scrollview, then dynamically fill the text in via code at runtime. They text should be very long, say about 20 mobile screens worth. Split that amount across the labels if using a single label fails to display or causes a crash. We test with iPod touches since their memory characteristics are relatively weak. Get device and editor on same Wifi and autoconnect profiler to see (hopefully) what we see in the profiler. Profiler in-editor produces strange results and we question their accuracy / relevance.
Many thanks, let us know if you would like further details.
Nicholas Bellerophon
Senior Developer
Yummi Media
4
NGUI 3 Documentation / Re: UIScrollView
« on: January 16, 2014, 12:46:39 PM »
Hi,
We love the CenterOnChild behavior and are using it to tween our scrollView. Sadly, however, if a user taps / clicks during the tween, the tween is canceled (or overridden?) and the scrollView stops where it is. It does not even snap back to the nearest child.
How can we prevent this behavior? We want the scrollView to NOT stop tweening due to a user press, but a user swipe should still override it with a new tween in the new swipe direction.
Many thanks!
Nick
We love the CenterOnChild behavior and are using it to tween our scrollView. Sadly, however, if a user taps / clicks during the tween, the tween is canceled (or overridden?) and the scrollView stops where it is. It does not even snap back to the nearest child.
How can we prevent this behavior? We want the scrollView to NOT stop tweening due to a user press, but a user swipe should still override it with a new tween in the new swipe direction.
Many thanks!
Nick
5
NGUI 3 Support / Re: Different anchoring when loading prefab dynamically or not
« on: December 13, 2013, 06:26:56 AM »
We've been wrestling with very similar issues here. The concept of the panel is just a bit confusing, at least to me. It suggests to me something physical, visual. But actually, although the panel does have physical location in the 3D / 2D space, it's "draw space" is separate from that.
I think I have a basic understanding, technically, of why this is the case.
However! Now you can change the panel to a clipping or constraining panel. And if you turn anchoring on, anchoring gets applied to the constraints / clipping, not to the physical position. This adds one layer of confusion. AND NOW on top of that we have the fact that scroll views use panels as the basis for their scrolling, so the physical position is moving but the clip area... uh... probably isn't?
And again, the technical argument is, well, how do you handle deciding how far the scroll view may scroll? You need some kind of bounds related to some kind of viewable area.
ArenMook, you have a real talent for making technically challenging things simple for users, as demonstrated by the vast majority of NGUI. Perhaps there is a simpler solution here too?
I think I have a basic understanding, technically, of why this is the case.
However! Now you can change the panel to a clipping or constraining panel. And if you turn anchoring on, anchoring gets applied to the constraints / clipping, not to the physical position. This adds one layer of confusion. AND NOW on top of that we have the fact that scroll views use panels as the basis for their scrolling, so the physical position is moving but the clip area... uh... probably isn't?
And again, the technical argument is, well, how do you handle deciding how far the scroll view may scroll? You need some kind of bounds related to some kind of viewable area.
ArenMook, you have a real talent for making technically challenging things simple for users, as demonstrated by the vast majority of NGUI. Perhaps there is a simpler solution here too?
6
NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion
« on: November 27, 2013, 06:31:35 AM »Nerophon: Masking with clipping can be doe by changing the shader used for the UITexture. See http://nickithansen.dk/masking-and-clipping-textures-using-shaders-in-ngui/
Ah, excellent! Thank you
7
NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion
« on: November 25, 2013, 11:15:56 AM »
Hi ArenMook,
Sometimes the best way to figure out what could use improvement is to have an ui/ux designer tell you what they want... and suddenly you have to implement it somehow. That's happening to me right now, so I'll share some general details of what was required, plus my conclusions about what seemed to be needed.
Firstly, we're doing mobile, so we need something that looks good on many different screen sizes and resolutions. Of course, the first issue was pixel density. As mentioned by others, the proper way to do ui for mobiles is to have a layout that is pixel-perfect at Density Independent Pixel scale, then changes based on density rather than height. This keeps things like nav bars the same size, no matter what device you're on.
After that, I found figuring out how to use anchor / stretch to layout elements in the desired way was a bit clunky. I am happy to hear you are going to try something new. In respect of this, one task I had was to create a bar that stretched across the screen, containing three buttons laid out in a grid. I naturally thought of UIGrid, but the spec was for a fixed pixel space between the three buttons, with the buttons stretching equally to fill the space. UIGrid cannot do this as of now, so I had to do it manually. Therefore, perhaps a grid upgrade is in order? And what about those super awesome grids you find on the net these days that have various sizes of squares, e.g. www.ted.com? That would be cool.
Next is a gripe: I implemented a scroll view, without softClip, prior to 3.0.6. It worked fine after I looked at the examples for a bit. However, now suddenly in 3.0.6 it broke because there's an automatic change to softClip in Awake. So I went back in and commented it out. But why force softclip on scroll views? Our scroll-view just goes off the sides of the screen.
Also, because of the layout system, I had to write my own UIAnchor subclass called UIAxisAnchor for our scroll view, which anchors in a single axis only. This required changing some of your private methods and fields to protected, which has been mentioned by others. But also, it suggests that the stretch / anchor system is, as stated above, not really sufficient for all use cases.
Speaking of that, the spec for our scroll view was that the elements needed to be a specific number of pixels less wide than the screen width. Again, I couldn't find a way to do this directly with NGUI, so wrote a script that does it in update. Obviously, not super-efficient. Perhaps I will have it do it once on launch, or do a screen-size change event or something. Perhaps NGUI could provide this? Or maybe it already does... who knows?
A final thing I've been asked to do is rounded corners. Easy enough you say! But wait! How about rounded corners on dynamic images downloaded at runtime? Ahaha! Harder. So perhaps, as mentioned by others, some kind of ability to use non-quad meshes, or some other solution to the problem of "masking with alpha".
Okay, that's all for now. As I continue implementing things, perhaps I will encounter more ideas for improvements. If so, will post.
Many thanks,
Nicholas Bellerophon
EDIT: turns out the spec for the scroll-view actually asks it be an infinite loop, including auto-scrolling on a fixed period, with breadcrumbs indicating current location. Looks like I'll be doing a fair bit of work here to turn a standard NGUI scroll view into this "carousel" thing. Hope this is useful.
Sometimes the best way to figure out what could use improvement is to have an ui/ux designer tell you what they want... and suddenly you have to implement it somehow. That's happening to me right now, so I'll share some general details of what was required, plus my conclusions about what seemed to be needed.
Firstly, we're doing mobile, so we need something that looks good on many different screen sizes and resolutions. Of course, the first issue was pixel density. As mentioned by others, the proper way to do ui for mobiles is to have a layout that is pixel-perfect at Density Independent Pixel scale, then changes based on density rather than height. This keeps things like nav bars the same size, no matter what device you're on.
After that, I found figuring out how to use anchor / stretch to layout elements in the desired way was a bit clunky. I am happy to hear you are going to try something new. In respect of this, one task I had was to create a bar that stretched across the screen, containing three buttons laid out in a grid. I naturally thought of UIGrid, but the spec was for a fixed pixel space between the three buttons, with the buttons stretching equally to fill the space. UIGrid cannot do this as of now, so I had to do it manually. Therefore, perhaps a grid upgrade is in order? And what about those super awesome grids you find on the net these days that have various sizes of squares, e.g. www.ted.com? That would be cool.
Next is a gripe: I implemented a scroll view, without softClip, prior to 3.0.6. It worked fine after I looked at the examples for a bit. However, now suddenly in 3.0.6 it broke because there's an automatic change to softClip in Awake. So I went back in and commented it out. But why force softclip on scroll views? Our scroll-view just goes off the sides of the screen.
Also, because of the layout system, I had to write my own UIAnchor subclass called UIAxisAnchor for our scroll view, which anchors in a single axis only. This required changing some of your private methods and fields to protected, which has been mentioned by others. But also, it suggests that the stretch / anchor system is, as stated above, not really sufficient for all use cases.
Speaking of that, the spec for our scroll view was that the elements needed to be a specific number of pixels less wide than the screen width. Again, I couldn't find a way to do this directly with NGUI, so wrote a script that does it in update. Obviously, not super-efficient. Perhaps I will have it do it once on launch, or do a screen-size change event or something. Perhaps NGUI could provide this? Or maybe it already does... who knows?
A final thing I've been asked to do is rounded corners. Easy enough you say! But wait! How about rounded corners on dynamic images downloaded at runtime? Ahaha! Harder. So perhaps, as mentioned by others, some kind of ability to use non-quad meshes, or some other solution to the problem of "masking with alpha".
Okay, that's all for now. As I continue implementing things, perhaps I will encounter more ideas for improvements. If so, will post.
Many thanks,
Nicholas Bellerophon
EDIT: turns out the spec for the scroll-view actually asks it be an infinite loop, including auto-scrolling on a fixed period, with breadcrumbs indicating current location. Looks like I'll be doing a fair bit of work here to turn a standard NGUI scroll view into this "carousel" thing. Hope this is useful.
Pages: [1]