Switched to Registering Views - Performance Issues

Hey, I recently pulled down the release candidate for babylon 4.1 and switched my project rendering from the old flow to one with views. At any one time we only have a single registered view but I’ve noticed the performance has completely tanked since switching.

It appears the rasterisation thread and the GPU in chrome performance monitor are getting swamped for some reason. Is there any specific caveats to views that might be causing this? Do I need to make sure to resize the working canvas passed to engine on instantiation or something?

Here’s a screenshot of my profiler showing the timings.


The screenshot appears broken because the image host I used returns an extensions with png… smart… Clicking it will still take you to the host.

Hello and welcome!

So it is not JS for sure :slight_smile: Views are generating a memory copy to a second canvas so if the canvas size is large it could be a reason

Ideally I would love to see it live on a repro case to give you more info

I’m not seeing any difference in performance when changing the size of the view canvas. The work canvas is default size. Changing it with the view doesn’t seem to make a difference. It’s difficult for me to minimally reproduce this issue due to the size of our codebase. If I can find time I’ll give it a shot.

Hey Deltakosh,

I found a solution. I had a look at the source and I noticed that in Engine.prototype._renderViews we scale the rendering canvas to the width and height of the view canvas before calling drawImage(). When I register my view to the engine I now set the width and height of the rendering canvas so it matches like so.

const parent = this.engine.getRenderingCanvas();
if (!parent) {
    throw new Error();
parent.width = canvas.width;
parent.height = canvas.height;

Because I only have one view at any time it looks like I can get away with resizing the rendering canvas. But with multiple views the cost of rendering each with differing sizes to the render canvas would increase dramatically I imagine.

I would have thought that the initial call to _renderViews would sort this out when you’re using a single view though…

Well having just one view is not the goal of the multiview. Why using multiviews if you don’t have at least two views?

That being said, I will make sure to do the fix on the registerView :slight_smile:

We’re using multiview to initialize the engine/scene and allow anything in our app to view the scene without having to create a new WebGL context each time. Components containing canvas views are being mounted and unmounted repeatedly and should always see the current state of the scene without losing any material/texture/camera information that happened to be set from another view.

Makes sense now :slight_smile: I updated the registerView function