model-viewers (5.7MB) causes other primitive components to "lag" across the page when scrolling

[danksky]

I'm using model-viewer to display 1 model-viewer per card, and I have about 2-5 cards on the screen at any given time and about 11 models (5.7MB each) on the page total. Whenever I scroll down the page of cards, the models follow the scrolling fine (with low "latency"), and all of the other components, including the divs that hold the models and the text within those divs lag behind. What can be done to improve this experience?

P.S.
Even when the page is only showing one model (the others are visibility: hidden), there is enough lag to be noticeable.

[cdata]

@danksky thanks for reporting this! I must admit, that's not something I have heard anyone report before. Would it be possible for you to share a test case that demonstrates the problem so that we can play around with it?

Also, which devices and browsers did you experience this in?

[danksky]

Hi @cdata sorry for the delay. The asset I'm using is sensitive, so I was making a demo that I could share publically. In doing so, I didn't replicate the problem. There were 2 differences in the demo vs. the project where I experienced this lag effect:

1. The demo was using 2.2 MB models. My project was using 5.7 MB.

2. The demo excluded mapbox. My project has a dynamic mapbox component.

I still have some tests to do, but I'm assuming that also rendering the map is causing the lag.

Edit: With 2.2 MB models and a mapbox component, I reproduced the same lag effect.

[cdata]

@danksky very interesting. I know that mapbox is able to use WebGL, so it's possible that this causes complications. I'm very interested to see a test case if you are working on one :)

[danksky]

@cdata
Here ya go: https://model-viewer-mapbox-demo.herokuapp.com/

[cdata]

Wow, that is fascinating. Thanks for sharing this!

[cdata]

Alright, after a bit of poking, I think we uncovered the problem. It seems that the problem only occurs in Chrome (please let us know if you discovered this issue in other browsers).

Fundamentally, the problem is that the <model-viewer> elements are being rendered on the compositor, and their containers are not, so there is an async lag between the two as they paint.

One potential fix for this is to force the container to be rendered on the compositor by forcing it onto a render layer. You can do this in Chrome by setting a CSS property like will-change: transform or transform: translate3d(0, 0, 0) on the container. For example, I was able to set transform: translate3d(0,0,0) on <div class="demo-list"> and the lag in your demo disappears.

Please be aware that while this will fix the problem, render layers allocate GPU memory, and if they are overused you will see bad effects from them on mobile devices and possibly even desktop browsers. I recommend using the "Layers" tab in Chrome dev tools to analyze the cost of the layers you have created.

Kudos go to @azakus for applying his deep well of web platform knowledge to this problem 🍻