Messages

1

NGUI 3 Support / Re: Slow frames when enabling panels with many widgets

« on: April 04, 2014, 06:02:33 AM »

Thanks for the reply!

So, the issue is actually not that the UIPanel keeps or loses the reference, it's that the Panel has another dedicated drawing class (UIDrawCall) which uses the custom geometry that UIpanel supplies and draw stuff on the screen with that. So making UIPanel "lose reference" just means that it doesn't provide the geometry from the given widget.

Thanks for explaining. Still I see UIPanel as the one responsible for facilitating this process

Each time a new widget needs to be added, the entire geometry from that panel needs to be rebuilt, which takes time. There's no real way around this part, since moving widgets around has the same effect.

I think you are wrong, because when moving a widget, there is a possibility of changing panels, widget position etc., thus the need to rebuilt geometry. But when I simply want to hide the widget and I know that it will not change it's panel/drawcall then the geometry would not have to be rebuilt.

Arguably, you can make a certain part of the geometry be drawn as normal but with alpha = 0, so it's not visible, but I'm not sure this is a healthy structure at all.

I do not know how to solve it internally. Thanks for the pointer.
But why do you think this is not a healthy structure?
For me it is a fixed cost, instead of having big performance problems when enabling, disabling widgets.
This could be a nightmare on mobile. Similar situation is with shaders, that needs to be warmed up before usage.
Unity recognized this problem with shaders and added Shader.WarmupAllShaders, so that we can prevent big perf drops during gameplay:
http://docs.unity3d.com/Documentation/ScriptReference/Shader.WarmupAllShaders.html

2

NGUI 3 Support / Re: Slow frames when enabling panels with many widgets

« on: April 04, 2014, 05:03:32 AM »

I see a reoccurring performance problem that people have with enabling/disabling widgets.
It seems to be a basic use case for many.
I know that ArenMook has worked on the improvements in this area. Thanks!

@ArenMook
Is there a way to get it even more efficient?
I was thinking of adding a new state to widgets:
Visible/Hidden. It would indicate to Panel whether widget should be drawn, but without clearing any of the references. The less is required to change the better.
Of course when widget becomes Disabled then it also be made Hidden. When becomes Enabled then also Visible. Thus Existing behavior of Enabling/Disabling widgets would not change.
What your thoughts about it? Is there a better way of doing this?
Thanks for your hard work!

3

NGUI 3 Support / Re: GC Alloc each frame

« on: March 06, 2014, 03:40:24 AM »

Yes, and try using that with a scroll view.

In a scroll view when you are dragging something, ALL items are visible, resulting in a very large draw call. When you stop dragging, items get culled and the buffer returns to a much smaller version. In your case the buffer will always be large.

Furthermore draw calls are recycled, so if you have one large scroll view it may cause all of your other draw calls to become huge in size as well because you never release the memory.

Could we get a feature that would allow us to regulate this behavior?

Maybe a flag in UIPanel: AutoTrimBuffers on/off?
And an interface to trim the buffers manually would be nice.

4

NGUI 3 Support / Re: Disaster with BetterList performance

« on: November 07, 2013, 05:29:32 AM »

Same problem here:
http://www.tasharen.com/forum/index.php?topic=6287

The problem here seems to be with:
[1] void BetterList< T >.Sort   (   System.Comparison< T >    comparer   )
That Aren implements on his own and which is slow.

The name of parameter is not consistent with regular List<T>, which is:
public void Sort(   Comparison<T> comparison)

This is critical because List and Array implement another sort method:
public void Sort(   IComparer<T> comparer) [3]

And the sort method that would work perfectly with BetterList is:
public void Sort(   int index,   int count,   IComparer<T> comparer) [4]

Use this method for sorting as it is quick.

[1] http://www.tasharen.com/ngui/docs/class_better_list_3_01_t_01_4.html#a61855a957a241aaf9017671ec99e72d2
[2] http://msdn.microsoft.com/en-us/library/w56d4y5z(v=vs.110).aspx
[3] http://msdn.microsoft.com/en-us/library/234b841s(v=vs.110).aspx
[4] List http://msdn.microsoft.com/en-us/library/8ce6t5ad(v=vs.110).aspx
Array http://msdn.microsoft.com/en-us/library/k3e17y47(v=vs.110).aspx
Array http://msdn.microsoft.com/en-us/library/8kszeddc(v=vs.110).aspx

5

NGUI 3 Support / Re: Serious performance spikes with 3.0.2 and UIPanel.LateUpdate

« on: October 28, 2013, 04:22:47 AM »

@ArenMook
Are there any plans to resolve this issue? Or should we try on our own?

6

NGUI 3 Support / Re: Serious performance spikes with 3.0.2 and UIPanel.LateUpdate

« on: October 25, 2013, 01:24:49 AM »

This is bad.

I rather have constant, but small performance drop than a short, but big performance hit.

It would be great if we got some control over what happens when widget is disabled or enabled.
The typical usecase is that I disable a widget and then enable it some time later. It would be great if the widget did not cause the re-batching nor geometry rebuilding.
I would expect the re-batching to happen whe I destroyed the widget or the widget was no longer a child of the Panel.

Another typical use case is changing of sprite on a widget from the same atlas without the need to rebuild geometry. As we all know the more we do preprocessing in the editor the less processing is needed when the game runs.

7

NGUI 3 Support / Sliced Sprite handling changed for sprites with padding in 3.0.0g

« on: September 27, 2013, 02:48:37 PM »

I have a sprite in an atlas. The sprite is 200x160 dimensions and Top and Bottom Padding of 20 each. Border is all 0.

In 2.7.0 I would set localScale to 200x160 to make it Pixel Perfect. Padding was ignored.
In 3.0.0g I need to set width and height 200 to make it Pixel Perfect. Padding is not ignored.

Is this intended behavior?

8

NGUI 3 Support / Re: [Bug] Panel with lower z may be drawn under Panel with higher z

« on: August 17, 2013, 10:34:44 AM »

My fix ensures that Panel position Z is not taken into account when building widgets geometry.

What I do is:
1. Store Panel localPosition
2. Zero Panel localPosition.z
3. worldToLocal = cachedTransform.worldToLocalMatrix;
4. Restore Panel localPosition from 1.

This way I make sure that only Panel z position is taken into account when determining which panel should be drawn first as it is closer to the Camera and not widgets' geometry(that is currently based on Panel worldToLocal matrix hence also on Panel z position).

According [1] It is Panel's Z position that determines which Panel should be drawn first. But right now this is not always true as widgets's geometry is based on Panel Z position.

Example of the problem:
1. Panel1 has Z localPosition = -1
2. Panel2 has Z localPosition = 0
3. Panel1 widgets mesh is generated based on Panel1 worldToLocal matrix, therefor it is moved in z direction also by unknown value(I noticed that the value changes).
4. Panel2 widgets mesh in generated but not moved as Panel2 z is 0;
5. Set Panel1 Z localPosition = -0.5
6. Set Panel2 Z localPosition = -0.75

You would expect Panel2 to be drawn before Panel1(because it is close to camera), but this is not the case as Panel1 mesh is internally moved in z so Panel1 is before Panel2.

With the fix Panel2 will always be drawn before Panel1 as Panel's z position will not be taken into account when building widgets mesh.

[1] http://www.tasharen.com/forum/index.php?topic=1858.0

9

NGUI 3 Support / [Bug] Panel with lower z may be drawn under Panel with higher z

« on: August 16, 2013, 09:10:16 AM »

Panel with lower z may be drawn under Panel with higher z. Reverse is expected as Panel closer to the camera should be drawn first.

UIPanel.cs line line 713
void UpdateTransformMatrix ()
worldToLocal = cachedTransform.worldToLocalMatrix;
worldToLocal takes localPosition z of UIPanel. Later worldToLocal is used to calculate widget geometry.
The result is that UIPanel localPosition Z may not behave as expected.
Panel with lower z may be drawn under Panel with higher z(reverse is expected).

To fix when worldToLocal is assigned to make sure that Panel's localPosition z is always 0.0f.

10

NGUI 3 Support / [Bug?] UIGeometry.ApplyTransform has parameter normals that is not used

« on: July 29, 2013, 12:45:03 PM »

UIGeometry.ApplyTransform(Matrix4x4 widgetToPanel, bool normals)
Line 82

normals parameter is never used.

Unity 4.1.5f1
NGUI 3.6.3