[Webkit-unassigned] [Bug 236130] Low fps when mesh instances are scaled to 0

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Feb 8 15:22:21 PST 2022


https://bugs.webkit.org/show_bug.cgi?id=236130

--- Comment #7 from Kyle Piddington <kpiddington at apple.com> ---
Alright, I think I've got a potential answer. I'm not sure how much we can do to fix this one, but here's what I've got from a quick look. Would love a BabylonJS developer to correct me if I've got any of this wrong.

1) Where did the instancing go?
Looking into the Babylonjs source, it looks like there's some code to deal with rendering instanced meshes that has to deal with if a mesh is visible or not. Given that we're setting the scale of these meshes to zero, I assume babylonjs marks all instances as 'not visible.'

Assuming we're using the prototype 

 Mesh.prototype._renderWithInstances = function (subMesh, fillMode, batch, effect, engine)... 

When we go to render an instanced mesh, we may up getting an instance count of 1. 
(instancesCount = (renderSelf ? 1 : 0) + visibleInstances.length;)
This causes us to render each skull one at a time. Since we're rendering zero pixels, this should be a fast operation. But...

2) Why are we waiting for each skull to render?

Here's where it gets trickier. In between each mesh render, it seems that we get a call to bufferSubData to set a uniforms buffer up for the render. mapping the underlying buffer to send data, at the moment, causes a full render to occur. This means sending a command to the GPU, and waiting for a callback. I'm assuming, and to an extent observing that this wait is what's causing our problems.

My questions for the BabylonJS developers:
1) Am I reading this code correctly re: instances? If none are visible, they're drawn one at a time?
2) If so, is this a bug worth fixing in BabylonJS? We can continue analyzing slowdown here, but it seems like this might be undesired behavior.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220208/2fab6cf6/attachment.htm>


More information about the webkit-unassigned mailing list