1
\$\begingroup\$

I'm currently trying a new approach on a Card Game in Unity.

To capsuling my Card Prefab i have a root GameObject with the Canvas Component.

I'm highly count on the Canvas behavior which should render things after the main scene rendering.

Elements on a canvas are rendered AFTER scene rendering, either from an attached camera or using overlay mode.

Before i further proceed, i want to know if there are any disadvantage of this, when my Game Logic approximately generate 100-200 of this GameObjects?

Should the Canvas Component not be overused in Unity?

\$\endgroup\$
  • 1
    \$\begingroup\$ If anything, this should impact performance in a good way in a card game. Your cards won't update the whole canvas and instead update their own. forum.unity3d.com/threads/… I don't have any experience with many canvases in one scene but it shouldn't really affect performance in a worse way than many container game objects in one scene. \$\endgroup\$ – John Hamilton Apr 12 '17 at 11:13
  • \$\begingroup\$ You can also control render ordering on ordinary Sprites and geometry, so if your profiling suggests a large performance cost for many canvasses then you'll have alternatives you can use. \$\endgroup\$ – DMGregory Apr 12 '17 at 12:50
  • \$\begingroup\$ Watch this: youtu.be/n-oZa4Fb12U If anything, most devs are under using canvas objects. \$\endgroup\$ – Draco18s Apr 12 '17 at 14:44
2
\$\begingroup\$

Canvas is rendered in the "RenderOverlay" call in he render pipeline. If we are talking about screen overlay the canvas is simply rendered in 2D space over anything previously rendered, which always happens last. I'm not entirely sure why this was in your question?

The advantage of Canvas is that it can render multiple sprites in one go, if and only if their states are the same. The batching technique is mostly useful if you're drawing lots of things to the screen. I'm assuming that each canvas is holding its own buffer for vertices ( I can't be too sure about it but as John Hamilton stated, it suggest to be the case ). I'm not entirely sure if 100-200 canvases will help you with performance Per se.

The mesh of the canvas is build dynamically by pushing vertex data to the buffer based on their screen coordinates, size and scaling, this is done cpu side which is then uploaded to the GPU, so there is a bit of work involved for your computer.

So ideally if you have a layout that doesn't change, you want to keep that in a separate canvas so that the buffer doesn't have to be rebuild and uploaded. Likewise if you have moving parts you want to keep those in a separate canvas as well.

Going back to your 100-200 canvases, I'm not really seeing the advantage here by giving your moving objects several canvases. If my assumption is correct about canvases managing their own buffers, you're creating a lot of them, and it is also safe to assume these buffers are created bigger to accommodate at least a couple of sprites. You're wasting memory and you're doing a lot more calls to the gpu to update the data.

It isn't clear if those canvases have static layouts or moving parts either.

You have to test some of this yourself. Use the Frame debugger ( or RenderDoc) to see what is going on when objects are rendered and what buffers are created.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.