UIPanel

[ArenMook]

Yes, clipping and anchoring at the same time is possible -- however what you anchor them relative to is what matters. Anchoring one panel to another is not advisable. It's best to anchor panels to widgets or the camera. The widget can then be anchored to another panel if needed, although I strongly advise limiting the number of anchors used as they degrade performance.

[Cine]

Yes, clipping and anchoring at the same time is possible -- however what you anchor them relative to is what matters. Anchoring one panel to another is not advisable. It's best to anchor panels to widgets or the camera. The widget can then be anchored to another panel if needed, although I strongly advise limiting the number of anchors used as they degrade performance.

I cannot get it working though. No matter what I pick as the anchoring target for the panel, when I resize the target the part inside the panel is NOT moved/resized, although the panel itself is.

[Cine]

I finally figured it out... The anchoring in UIPanel is broken.
But if i ALSO make it a UIWidget and use anchoring there, it works just fine.

[WinWin123]

hello, I am really new in Unity. Wanna ask that what's the difference between StartAt and explicit in Render Queue?
And what's the relationship between Render Queue, sort order and the depth value in UIPanel?
Thanks @@ I'm confused about these concepts.

[ArenMook]

If you open up the Panel Tool, you can see what render queues your draw calls end up with. "Start at" means the draw calls will begin at the number specified, and go up from there. So if you have 3 separate draw calls underneath your UIPanel (for example an atlas, dynamic font, and a UITexture), and you chose the "start at" to be 4000, you will end up with draw calls 4000, 4001, and 4002.

Sort order is used by the Unity's 2D system. It's not something you should worry about unless you are mixing Unity 2D and NGUI underneath the same camera.

[WinWin123]

Thanks, That's very clear.
I am now having another concern.
I know that you encourage us to have a panel for each window.
I can see the advantage that solely setting the depth value of the panel can avoid windows mix up with each other if there happen to have two windows at the same time.
However, this increase the draw calls even when all elements in those panels are having same material or texture.
Is there any other ways to keep the draw call down to one in this case while I can still effectively handle the depth of these windows?
Thanks

[ArenMook]

Draw calls are created by panels. Separate panels = separate sets of draw calls. There is nothing that can be done about that, it's intentional. If you want fewer draw calls, use fewer panels.