Unity Ngui Performance Optimization

Readers are advised to read this blog first: http://blog.csdn.net/zzxiang1985/article/details/43339273, some techniques have changed, such as the 1th trick, Unity5 's packaging mechanism has changed a lot. Unlike other strokes basic can learn, such as: Transparent channel separation, close the texture read/write option (in fact, other resources read/write options are similar, such as animation resources, etc.), reduce the number of gameobject in the scene, Organize the atlas (typically a panel using 2 Atlas: The current panel is an Atlas + basic Atlas), using multiple UIPanel to separate the DC to avoid a DC change but redraw a large number of DCs.

Here are my main additions to the DC approach to reduce Ngui:

First, we need to know that the Ngui DC is UIPanel separated, and each UIPanel manages its own DC;

Second, for a uipanel, each DC has its own uiwidgets list, has its own texture/material, and UIPanel assigned depth depth range, DC-batch situation: the same texture, material, and the depth of 2 of the range is adjacent to the rendezvous batch. After the batch, the depth range of the new DC contains 2 DC ranges (in fact, it is not correct to read the source code, it is right that each uiwidget,uipanel will find an existing DC based on its texture depth: texture, same material, and the depth range of the 2 is adjacent, can not find a new DC to it);

Thirdly, the reconfiguration of DC: includes 2 kinds: UIPanel. Filldrawcall and Uipanel.fillalldrawcalls, as the name implies, the former is to a DC redraw, the latter is to the UIPanel all DC redraw, which is mentioned in the article at the beginning of the blog post.

The first refactoring is when a dc.isdirty is redrawn: Here we talk about non-manual redrawing and redrawing during the run:

There are vertex changes in the uiwidgets of 1.DC, changes in vertex position or widget transparency (the transparency of a widget is determined by the vertical structure of the entire widget, and the father's father's dad's ... ）

2.removewidget, so try not to run when Removewidget

At 3.addwidget

The second refactoring is when the uipanel.mrebuild=true is redrawn: Here we talk about non-manual redrawing and redrawing during the run:

1.addwidget, if you cannot find an existing DC to use for it, mrebuild=true,

2.removewidget, if the widget has a DC and the depth of the DC is the minimum or maximum depth of all DC depths in the UIPanel, mrebuild=true

Summarize:

For the first, UIPanel very few, the DC will affect very big, if a DC often lead to fillalldrawcalls, that everyone together suffer, but if uipanel a lot, itself increased a lot of DC, because the DC between the UIPanel is independent, can not be combined with the , so do not abuse uipanel in the project;

For the second third, the actual application, generally the jumping words, blood bars and other frequently redrawn UI separated as a UIPanel, the main panel of the UIPanel can be divided into: Staticpanel,movepanel1,movepanel2 ..., And you can see that the Remove and add widgets have a big impact on repainting, so try not to run when you do both things, unless you know what will happen.

In addition, for a system of the panel, generally use their own Atlas and public Atlas, this time to pay special attention to the same batch of DCs, to avoid the different Atlas Uiwidget depth cross caused the same Atlas widget DC cannot be batched, I am in the UI panel general < 1 depth to the background map, 1-9 to the public Atlas, 10-20 to the system's Atlas, 50-60 to the public atlas, so that basically do: can be combined with the batch, the actual work to form a click UIPanel showdrawcall, open the DC display panel, See if the segmentation is too powerful or can be combined, the habit.

Unity Ngui Performance Optimization