HTML layer drawbacks?

0 favourites
  • 4 posts
From the Asset Store
Get ready to dive into a sea of endless excitement with "Dolphin Jump," the thrilling new game that puts you in control
  • I'm sure there's some kind of drawback to changing a layer to an HTML layer, or else it wouldn't be something off by default. I can't seem to find info on it.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Not that I'm aware off. Worst case I assume it has some performance overhead which is not really a drawback but a trade-off.

    ...or else it wouldn't be something off by default

    The reality is it's probably off by default simply because most layers don't need to be HTML layers. It would make no sense to make it a default if by default it's not needed.

  • The way HTML layers work is by creating an additional <canvas> element per HTML layer, so other content can be drawn to that and layered above other HTML content. However this has quite a high performance overhead. Firstly and probably most significantly it will use a lot of GPU fill rate as it has to draw at least one additional viewport-sized texture (and possibly 2-3 depending on the realities of compositing) - a similar overhead to using one or two 'own texture' layers. Secondly it will also use more GPU memory as it allocates another viewport-sized surface (and possibly 2 depending on details like double buffering). A HD (1920x1080) size surface is about 14 MB.

    My advice is to only use the minimum necessary HTML layers to avoid unnecessary performance overhead.

  • Ah thanks, that makes a lot of sense and helps a lot with planning out how to use them. I remembered something being said a long time ago about why HTML elements always appeared over objects (like sprites) and thought it might take some kind of overhead like own texture but different to make it work.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)