Messages

1

NGUI 3 Support / Re: Making menus appear not jerky

« on: December 06, 2014, 06:00:02 AM »

Yes, got that, so i want to render them, with alpha 0 and need a way to toggle it to have them do all the layouting stuff even when alpha 0 so then when i turn their alpha up they are all properly layouted (all the anchoring stuff etc should have taken place while their alpha was still 0 )

2

NGUI 3 Support / Re: Making menus appear not jerky

« on: December 05, 2014, 05:14:02 AM »

Keeping things enabled and "just" off screen is a feasible solution for some things but not for many others.
I can use that way for a simple small popup window for example. But for more complex content like let's say a full splitscreen layout of many elements anchored to different screen edges and among each other, first positioning it off screen would then lead to jerky repositioning/re layouting on first move into the screen then, too, so first positioning all outside the screen is useless then.
Next to the side that having lots of elements which are not used in that moment positioned outside the screen is no good performancewise either.

One should also in general be able to turn that ngui internal "ignore if alpha<x" "optimisation" off for objects since it causes issues on various other ends, too. Like for example when one has buttons with transparent hit area (sprite) and they are supposed to resize to certain screen dimensions but resizing and pressing them does not work cause they have alpha 0 so one then has to set their alpha to a low value but not 0 to make them work properly.

3

NGUI 3 Support / Re: Making menus appear not jerky

« on: December 04, 2014, 06:13:50 AM »

I was busy with a few other things in the meantime and just got to this again now.
So i tried setting the panel's alpha to 0, sadly for some things this does not work due to some i guess optimizations things you did because when the alpha is set to 0 for an object actually some sizing etc code seems to not get executed.
So when i have for example a popup panel and it has text and other elements resizing dynamically and the panel bg and other elements adapting to that and i would set the panel's alpha to 0 and set the text (so the layout, panel bg etc should resize), then it only does that resizing/reflowing of the layout once i set the alpha of the panel to higher again, not while its set to 0.
So setting it to 0 then is useless (despite it is what would be good to do to have it be shown once its properly layouted).
Is there some way to disable your "don't do if alpha ==0" or similar optimisations for that use case then?

4

NGUI 3 Support / Re: Making menus appear not jerky

« on: November 20, 2014, 01:05:22 PM »

ok, i'll give that a try, thanks =)

5

NGUI 3 Support / Making menus appear not jerky

« on: November 19, 2014, 02:10:15 PM »

So here's the issue:
When i have ngui ui elements enabled and on the screen on app start, all looks fine.
But i have some items which are not enabled by default or added at runtime or resize in between etc.
Menus with scrollviews and header bars and panels which resize fitting to the screen dimensions, list items which reflow based on dimensions of previous elements etc.
And those all come in in jerky way the first time enabled/shown.
Its like it takes a frame or two for all the things to adjust to  dimension changes or content changes, changed anchors etc.
Is there some method(s) one can call to force it making all aligned and adjusted well right away when enabling it and showing it right in that frame the way it would usually display a few frames later?

6

NGUI 3 Support / Re: Heavy performance impact and battery usage with complex menus

« on: November 14, 2014, 06:45:19 AM »

The LateUpdate on all the UIPanels is called constantly and then also Updates on many UIRects.
Regarding the UIRects: on many of them i set it to not update every frame, but for many i also have to set them to update every frame.
That is because the app reacts to changing screen size and device orientation.
So as i said, there should be another option next to only once and constantly in update, which should be only when needed and should only be triggered when the content changes, the camera changes or the screen (resolution or orientation) changes.
So then all could reflow and then afterwards not running again until having to reflow again due to one of these setting it dirty for one frame

7

NGUI 3 Support / Heavy performance impact and battery usage with complex menus

« on: November 12, 2014, 09:11:17 PM »

So yeah, when having complex menus with scrollviews, lots of list items, anchored items around the screen etc, this has a way higher performance impact and battery using (on mobile devices) impact than it should.
I think this is due to good part due to the many UIRect/Anchor Update calls and UIPanel LateUpdate calls.
When i check the profiler, those NGUI things run constantly on all the items and have a considerably performance impact in total.
Ideally there should be a way where one can tell it to only Update when needed, which should be:
-when own or nested content (dimensions, color, pos, rotation, scale) changed
-when camera changed (position/rotation (,size for ortho cams))
-when screen changed (resolution/ screen orientation)
right now it is just calling all this stuff way too often (constantly).
And for anchors the option to do it only in start is no good either, let's say for cases like the device orientation changes and thinks should of course re layout, but then not re layout constantly anymore in update when nothing changed.

So yeah, would be great if there could be an option to do all those updates only when one of these 3 items is dirty/changed.

8

NGUI 3 Support / Re: Unity 5 Bugs

« on: November 07, 2014, 02:27:03 AM »

Ok, nice, thanks =)

9

NGUI 3 Support / Re: Unity 5 Bugs

« on: November 04, 2014, 11:36:52 PM »

@Aren: i sent you a pm with NGUI with the scripts updated for U5B11, hope it helps =)

10

NGUI 3 Support / Re: Unity 5 Bugs

« on: November 04, 2014, 11:27:35 PM »

The auto updating scripts does not work with the latest beta when having NGUI 3.7.5 in the project and the scripts for that should be auto upgraded. I filed a bug report on that one.
That said: so since the auto updating script failed initially, i then restarted the editor and started manually fixing the issues and then after fixing a good amount of them that way, i then closed the editor again, opened it again and chose to try it again with the auto updater and then it worked.
So then i got it all updated =)
So the auto updater was seemingly getting stuck somewhere and manually fixing that one issue then made it be possible to run through for the rest.


As bottomline though, yes, after auto updating, still flipped letters in ngui labels :I =)

11

NGUI 3 Support / Re: scrollview does not snap to top

« on: November 04, 2014, 10:08:02 PM »

Right, that's just how NGUI's scroll views work. Restricting within panel does exactly what it says. There is no "spring to top" option. If you really want it to spring to the top rather than to the point where its content is all visible, you'll need to write a script to do that or modify the code to suit your needs.

Hm, ok, will do that, but yeah, i think that is a feature one would totally expect the scrollview to have and do automatically =)

12

NGUI 3 Support / Re: scrollview does not snap to top

« on: November 03, 2014, 08:59:53 AM »

It's not a bug. Cancel drag if fits simply lets you or not lets you drag the content depending on whether if fits or not. It won't snap the content to the top for you. You can change that by setting UIScrollView.SetDragAmount(0, 0, true).

Hello Aren, thanks for the reply but i think we're not talking about the same thing because what i'm asking for is very standard behaviour for every scrollpane/view out there. When one drags the content down, on release, it should ease back up to the top, just like on iOS scrollviews or any other where one can drag the content with the finger like that.
No matter if one has "cancel drag if it fits" toggled off or on,  i'd assume having "restrict within panel" toggled on  should make it do exactly that (not just restrict it within the panel as in scrolled out at the bottom but also restrict it within the panel as in scrolled further down than content top)
Just triggering UIScrollView.SetDragAmount(0, 0, true) is no good since it makes it just jump to the top, not animate there nicely (as it does when one drags the content downwards outside the scrollview where on release it eases it back using springpanel, so basically it should do the same when dragging it downwards below the top of the content and releasing it).
I'm sending you a pm with a link to a video showing the issue to go sure we're talking about the same thing =)

13

NGUI 3 Support / scrollview does not snap to top

« on: November 02, 2014, 11:03:11 AM »

So when using a UIScrollView and having toggled on "Cancel Drag if it fits" for it or if the content inside the scrollview is as tall or taller than the scrollview area (so it would perfectly fit without need for scrollbar or have to scroll anyway) and one drags the scrollview's content up or down, it tweens nicely to snap back to the top of the scrollview area when one releases it.

But when one has "Cancel Drag if it fits" disabled for the scrollview and the content in the scrollview is not as tall as the scrollview's area and then one drags the content and releases it, then snap easing back to the top does not work well for the content.
It works when dragging the content up and releases it, but when dragging it downwards and then releasing it, it only eases to scrollview top position+(difference between scroll view area height and  scrollview content height).
So the scroll content is then floating lower down instead of being moved back up fully to the y offset position of the scrollview.

Is this a known issue? Any thoughts on addressing this/working around it?

14

NGUI 3 Support / Re: Caret not showing on devices

« on: April 20, 2014, 04:01:21 PM »

I changed the UIInput.cs quickly now to on mobile just show the caret where the last letter of the textfield is, yes it doesnt show a selection range, but still, imho way better than not having a blinking caret shown at all =)
Would be cool if you could add something like this in NGUI so i don't have to edit the builtin class again after the next update =)

http://www.stimunation.com/betatests/NGUI/UIInputWithCaretOnMobile.zip

15

NGUI 3 Support / Re: Caret not showing on devices

« on: April 20, 2014, 03:36:35 PM »

This doesn't make sense to me, i mean i show the UIInput and want to show the input field in ngui and hide the native input textfield, what good is an input textfield if it doesn't even show a caret to indicate where one is editing it?
Why can't you on mobile just show it at the current position of the label if it is selected (where you also add the next letter typed) ?