[The following is my original unedited query regarding a non-fatal error notice.]
All of my WebGPU programs are now showing the following error notice.
THREE.Renderer: “hasFeatureAsync()” has been deprecated. Use “hasFeature()” and "await renderer.init() when creating the renderer.
This is a bit odd because I am not using and never have used hasFeatureAsync(). I am using await renderer.init(), but not “hasFeature()”
But none of the official WebGPU examples appear to generate this error - regardless of whether they use await renderer.init() or not. (I have not seen any that use “hasFeature()”).
I am assuming that something in my setup must be causing this error notice and am searching through the official examples for clues. In the meantime, what kind of setup might generate this error notice?
[revised, and revised again, in the interest of brevity]
Thanks for your offer! While attempting to create a smaller file to illustrate the problem, I started deleting routines. I soon realized the stats-gl module appears to be the problem. Apparently, stats-gl is no longer compatible with WebGPU.
I think you can safely use the performance measurement feature of the new Inspector which acts as a replacement for the previous `stats.js` and `stats-gl.js`. We couldn’t replace these modules in all examples with the new Inspector yet. So you might see a few demos still uses `stats.js` or `stats-gl.js`.
Sidenote: The Inspector uses GPU Timestamp Queries so it should be equally precise as `stats-gl.js`. If you encounter a bug with the Inspector, please report it at GitHub.
From a visual inspection of all WebGPU examples, none use stats-gl.js and only this program uses stats.js. It looks like someone spent a lot of time upgrading and improving all of the examples. Thanks!
For me the Inspector does not show FPS and its chart when running a WebGL2 browser. There is a message in the console that WebGPURenderer timestamp tracking is disabled.
Indeed, that is a known issue. I believe @sunag plans to improve this. If timestamp tracking can’t be used, we could fallback to the Performance interface.
Sorry for the migration efforts but we have realized that the many duplicated async methods ( renderAsnyc(), clearAsync() etc.) only made the API more verbose and also produced confusion about their behavior. These methods did no render or clear anything in an async fashion, they only used await renderer.init() internally. It turned out it’s better to move this call to the application and let the developer control what to do after the initialization. In this way, we have no duplicated methods and a more transparent renderer behavior.