Messages

1

NGUI 3 Support / Re: Bug Report: Missing Transform Handles (Unity 4.5)

« on: June 23, 2014, 09:06:04 AM »

Ah, this explains an issue that we had seen in 4.5 with a somewhat old version of NGUI. The move gizmos were missing entirely in 4.5, even when in 'Handles Off' mode.

That version didn't have the '&& UIWidget.showHandlesWithMoveTool' check, and adding that fixes it.

We're generally using 'Handles Off' mode, as it avoids accidental scaling of small widgets, and makes it easy to constrain movements to a single axis

2

NGUI 3 Support / Re: Poor Custom Font Quality

« on: March 19, 2014, 04:42:55 AM »

I wrote a blog post a while back about bitmap fonts, and how to get them looking decent. Not specific to NGUI, but it applies to NGUI or any similar system where bitmap fonts are used and likely to be scaled:

http://inverseblue.com/?p=268

Basic things to do are:

- Export the font at a larger-than-needed size
- Enable mip mapping and trilinear filtering
- Use a small negative mip bias to keep things sharp

For the mip bias, you'll need a tweaked copy of the NGUI shader, using tex2DBias() (I posted a few notes about that, too: http://inverseblue.com/?p=287 )

3

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

« on: December 10, 2013, 09:41:21 AM »

There is no need to convince me, you already have. I already said I'll change it soon. It won't be back to 2.7 days, but I will make it so that widget changes only affect their own panel.

Cool, this sounds good

What's likely to be different/slower compared to 2.7? -  are you planning to keep the global widget list, or go back to widget lists per-panel?

4

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

« on: December 09, 2013, 06:55:34 PM »

This is resulting in spikes for us too, 7-10 ms in a iPhone 5.

We don't see any way of not firing a mRebuild when enabling/disabling components. How are we supposed to hide/unhide components without triggering a full rebuild? I think that panels should be independent, a widget in a panel which has a different depth than other panel should not fire a full rebuild. Panels not being able to share their depth seems the right thing to me.

We are still looking for a solution. Bluescrn, would it be asking too much sharing your code modification?

Thanks

To be honest, I'd rather that we try to convince ArenMook that bringing back independent panel updates is essential, as these unavoidable full rebuilds are causing severe performance issues in real-world mobile projects. It's a serious drop in performance over 2.x, especially if you're trying to use NGUI for highly-dynamic in-game HUD elements.

My modifications are fairly significant, not particularly pretty, and spread across a number of files. And they're not perfect. Although it's working fairly well in our project, I've got at least one or two tricky bugs still to deal with (draw calls disappearing in the editor after recompiling scripts). I've also only got them working with 3.0.6f6, which is already somewhat out-of-date. But 3.0.7 seems to be a fairly large update, so merging may be tricky.

Not yet sure whether we'll do that for our project, or maybe just try to fix up 3.0.6 by bringing in the most critical fixes from later versions (for example, the slow font/atlas selectors, which are now fixed in 3.0.7)

5

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

« on: December 02, 2013, 10:29:26 AM »

A cheap way to get around the list rebuilding would be to ensure that there is already a widget active using the same atlas and within the same draw call.

I briefly experimented with that sort of solution, but it wasn't working out too well - it avoided the spike when enabling the widget, but removing it still caused a spike, due to this:

1. if (depth == w.drawCall.depthStart || depth == w.drawCall.depthEnd) mRebuild = true;
2.  

         

And there were lots of things in our HUD scene still triggering the expensive UIPanel.mFullRebuild (for example, enabling/disabling panels for pop-up HUD elements - less frequent events, but still an undesirable performance spike)

Our GUI layouts are not ideal/optimized, there can be quite a lot of draw calls. It's mostly just two fonts and a HUD atlas, but split into a number of panels, and layered up in a way that doesn't batch amazingly well. But they're split up in such a way that no panel contains more than a few widgets, so a single-panel update should be a cheap operation. But with 3.0.x, panels are not independent, and it's easy to cause a rebuild of the entire HUD.

I've spent some time now modifying the internals of 3.0.6f6 fairly significantly (mostly UIPanel/UIDrawCall) to make panels independent again:

- mFullRebuild is per-panel
- Widget lists are per-panel
- DrawCall lists are per-panel
- Panel depth directly controls the render queue of the first draw call in the panel

So nothing will force a rebuild of all panels, at worst there'll be a single-panel update (and minor changes will still only update the single draw call). It seems to be working fairly well so far...

There's a definite trade-off between optimizing draw calls and optimizing update speeds. If you have a complex UI down to one draw call, any small change to it will mean an expensive rebuild of that draw call.

If things are split into more independent panels/draw calls, updates are likely to be less expensive. And in our case, a few more draw calls is a fairly smalls sacrifice to avoid big performance spikes.

6

NGUI 3 Support / Re: 3.0.6 - Per-font spacing settings gone?

« on: November 28, 2013, 03:17:04 PM »

Wow, I didn't realise you could search the hierarchy by type like that! (I've frequently wanted to...) - that's great, thanks!

7

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

« on: November 28, 2013, 07:24:26 AM »

I've now updated to 3.0.6.  It may have made the spikes smaller, but they're still big spikes that weren't there with 2.x.

It looks like I'd misunderstood the problem yesterday. It's not just instantiation - With 3.x, it seems that enabling/disabling a widget has become a very expensive operation?

With 3.0.6, on a Nexus 7, I'm getting 7-9ms spikes whenever I update small elements on our HUD. (This happens every time a shot is fired, so it's quite a big deal)

When enabling widgets, UIPanel.InsertWidget is setting mRebuild flag, causing an expensive full update. (Yes, only if it needs a new draw call, but in practice that happens most of the time in our scene)

With 2.x, NGUI had never been a real performance concern in-game. Small updates to small/simple panels seemed inexpensive. We certainly weren't seeing spikes like this. Panels were independent, and updating a small panel was fast. But now, it's forced to update all visible panels/widgets, and grouping things into panels doesn't help keep performance managable.

I can't see any obvious way around it. It's looking like the improvements to sorting in 3.x came with a very high price for some scenes?

Is there anything that we can do to regain some performance, other than reverting back to a 2.x version of NGUI?... 

(I'm starting to wonder whether I could modify NGUI 3.x myself to use per-panel widget lists/updates/draw calls, to keep panel updates as independent as possible without reverting to an old version)

8

NGUI 3 Support / 3.0.6 - Per-font spacing settings gone?

« on: November 28, 2013, 05:49:05 AM »

Hi,

I can see that the spacing settings can be set per-label in 3.0.6. But the settings from existing bitmap fonts in existing projects are gone.

This is a pain if you've got hundreds of labels in a project, and need to set/change spacing values for a font. Can't we have both?

9

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

« on: November 27, 2013, 01:30:41 PM »

We've recently moved to 3.0.5, from a fairly old 2.x build, and have been getting some fairly large performance spikes during gameplay that weren't happening before, when updating some fairly simple HUD elements (in a scene with a fair bit of other UI loaded but turned off, but a relatively simple HUD, with no panel containing more than a few widgets)

In our case, it looks like it's related to instantiating widgets - I'm instantiating a number of small HUD popups (e.g. floating score text, health bars). This is already done through an object pooling system, but the objects are stored outside of the target panel (and become children of a PoolManager object instead)

When these objects are spawned, UIPanel.mFullRebuild gets set. And it looks like this is now a global flag (for the whole UI), rather than a flag per panel (as in 2.x)? - and in our case, it results in a much more expensive UIPanel.LateUpdate than before (a few millisecs on the Mac build, significantly more on a mobile device)

I suspect/hope that I'll be able to fix these cases by pre-allocating and pooling the spawned objects within the destination panel, avoiding any instantiation/re-parenting, but I've not had a chance to try that out yet.