-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
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
WebGLRenderer: Defer blocking queries against WebGLPrograms after linking. #19745
Conversation
dbb5a45
to
cea4a5a
Compare
Review ping? |
e575855
to
13f6f5b
Compare
Thanks for the feedback! Addressed all comments. |
I've tested your branch locally and it seems the |
I'll look into it, thanks! |
13f6f5b
to
f4222b3
Compare
Fixed. Explanation above. |
5800fb4
to
8574346
Compare
Program linking can happen asynchronously, but is forced to block and wait for completion the first time information about that program is queried after linking. This includes calls to getAttribLocation/getUniformLocation/getUniform/getProgramParameter/getProgramLogInfo, etc. This change defers most of those calls until the first time until the first time that they're actually needed by the page, which can allow the program linker time to complete and thus reduce blocking, especially when used in conjuntion with renderer.compile(). It's worth noting that many materials are initialized the first time they are encountered by the render loop and then immediately used for rendering, which negates most of the benefit that this could otherwise provide, but it lays the groundwork for more efficient patterns in the future and can significantly help classes like PMREMGenerator that are already using renderer.compile() internally.
📦 Bundle sizeFull ESM build, minified and gzipped.
🌳 Bundle size after tree-shakingMinimal build including a renderer, camera, empty scene, and dependencies.
|
8574346
to
8ef3f65
Compare
Rebased to resolve merge conflicts after discussion kicked up on #19752 again. |
Since I think Ricardo feels positive about this change and supporting |
Thank you! |
Program linking can happen asynchronously, but is forced to block and wait for completion the first time information about that program is queried after linking. This includes calls to
getAttribLocation
/getUniformLocation
/getUniform
/getProgramParameter
/getProgramLogInfo
, etc.This change defers most of those calls until the first time until the first time that they're actually needed by the page, which can allow the browser time to complete linking asynchronously and thus reduce blocking, especially when used in conjunction with
renderer.compile()
.It's worth noting that many materials are initialized the first time they are encountered by the render loop and then immediately used for rendering, which negates most of the benefit that this could otherwise provide, but it lays the groundwork for more efficient patterns in the future and can significantly help classes like
PMREMGenerator
that are already usingrenderer.compile()
internally.The ideal endpoint is for Three to start taking advantage of KHR_parallel_shader_compile as proposed by #16321 and #16662. This is just a lower-impact stepping stone along the way.