-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty filter produces WebGL warnings / render issues when many plots share a single renderer #201
Comments
Which version are you guys running and have you tried asynchronous rendering as suggested in the linked ticket? |
Latest. The repro I linked above should be using the async rendering too, unless I made a mistake there? |
I haven't had a chance to look into the linked code example yet. Assuming this is an issue for your company (hema.to), have you guys tried to debug what might cause the issue? I welcome a PR in if you discover a fix for the issue. Otherwise I can take a look once I have some free time. |
Yes, I can try and lobby for some time to fix this. |
This bug might be fixed in #208. Would be great if you could give the PR a try. |
@flekschas thanks for the head's up. 🙌 I tested #208 with the repro case and the bug is still present. |
The bug has nothing to do with #185 it turns out but was related to an edge case where you filter out all points. Not sure why rendering zero instances can trigger the WebGL issue. |
When many plots share a single
renderer
instance, calling.filter()
with an empty array[]
produces WebGL warnings. In Firefox, this borks the plot for any subsequent render, see reproduction and video below, Chrome also has some render issues.Reproduction: https://stackblitz.com/edit/vitejs-vite-mdmiba?file=src%2Fmain.js
Screen.Recording.2024-11-29.at.13.55.25.mov
This only happens when both are true: filter is called with an empty array and a shared renderer instance is used. If each plot uses its own WebGL context, this does not happen. If
[undefined]
is passed as a filter, this does not happen.This is potentially related to #165.Not relatedThe text was updated successfully, but these errors were encountered: