Menu and buttons with DOM or Sprites?

Hi !

To add buttons and menus on the top of a scene, what is the more efficient, between having DOM elements and change their visibility with CSS through JS, or having a 2nd renderer with an orthographicCamera that show Sprites ? Or any other solution ?

What do you do usually ?

For typical screen-space (non-diegetic) UI elements I normally use ordinary HTML elements styled with CSS. It’s the easiest way for creating a user interface and way more flexible than working with sprites or billboards. The main disadvantage is that HTML based UI elements do not work in VR. In this context, you actually have to render UI elements with WebGL.


Thanks a lot for your answer !
And what about optimization ? Let’s say I have a bunch of information to write at runtime in several DOM element, is it still OK to access the DOM at each frame ?

1 Like

Well, I can only say that I had no performance problems in the past. For example stats.js, the performance monitor used in many three.js examples, is also updated per frame.

1 Like

I had a look at stats.js, I didn’t realize that it worked with a div element,
Thank you for this clear answer.

I have heard it mentioned a few times that overlaying HTML on a threejs scene is bad for performance. It’s probably not noticeable with stats.js since it’s a tiny box.

For example, these guys recommend using pixi.js for the 2d elements:

I think it would be interesting to see real performance metrics or benchmarks which illustrate the difference between HTML based UI elements and sprites.

1 Like

In the meantime, I made more experiences in this area I would like to share:

I have decided to use sprites similar like in this demo for certain parts of the user interface in my current project. It works great so far but then I have encountered the following issue:

I’ve used a sprite to visualize the amount of remaining ammunition of a game entity. The information is rendered as text on a 2D canvas which is used as a THREE.CanvasTexture. It’s the map of the sprite. The problem is when the content of the canvas does frequently change, you have a lot of texture updates and thus texture uploads. Although the resolution of the texture is not high (256x128), I could analyze a performance hit in Chrome developer tools when the respective texImage2D call happens. It seems that displaying the information as HTML and just updating the textContent is more performant in this scenario. I wonder if other developers made similar experiences :thinking:?