I did not say your wishes are unreasonable. Just that here is not the place for them. The person you replied to works on WebGPU and is quite buisy with that ..
Ignoring users and project architects is hardly a new problem by any stretch of the imagination. Leave the noted key features out, and the GPU API will remain vestigial. =3
I think what lukan is trying to tell you is that if you're serious about your advice being taken, you will need to find a venue in which the right people in the web ecosystem can engage with it. Neither me nor my team are the right audience for that, unfortunately. I suggest you file an issue on Bugzilla, if you want to start there! I'm happy to assist in making that happen, if you want.
If you do actually follow up with the above, I think you need to answer first: What APIs already exist on the web platform, and why are they not sufficient? For example, the Gamepad API exists; were you aware of it before, and do you think it fulfills the stated use case? Why or why not?
I will also push back on these statements:
> If people want it to be relevant to its primary use case, than low-latency HID interface callbacks are certainly required...
> Leave the noted key features out, and the GPU API will remain vestigial. =3
...because it appears to ignore valid use cases that exist outside of gaming. My team doesn't just serve the gaming use case (though we sure hope it will), and calling the API we're working on "vestigial [without supporting gaming]" is disrespectful to both people who need those other use cases filled _and_ people like me who are trying to make them possible. It also implies a responsibility for the platform as a whole that we can't possibly shoulder ourselves; the amount of expertise required to make a platform across all major OSes for just _one_ of these web platform APIs can be huge, and WebGPU is, indeed, very large.
Your team needs to consider _why_ the history of VRML browser standards ended up fragmenting, becoming overly niche, or simply being replaced with something proprietary.
I am unaware how perceived disrespect is derived from facts. If you choose to be upset, than that is something no one except yourself can control.
Certainly APIs can grow in complexity with time, but this is often a result of unconstrained use-case permutation issues or the Second-system effect.
Have a great day, and certainly feel free to reach out if you have any questions, observations, or insights. =3
I'll give one example (as it's one I was personally invested in). Doing a barrier in non-uniform control flow is wildly unsafe undefined behavior (I've had it reboot my computer, and it's easy to believe it could be exploited by malicious actors). To make these barriers safe WebGPU does a "uniformity analysis." However, that in turn required adding uniform broadcast intrinsic to the shader language, otherwise a class of algorithms would be impossible to express.
As I say, it's plausible this kind of work could have been done as extensions to WebGL, but I think the end result would have been a lot less compelling than what we have now.
Rather WebGPU and Apple's OpenGL lack of support for compute shaders.
Which became irrelevant the moment Chrome decided to move WebGL on top of Metal via Angle, just like it does with DirectX on Windows.
So it is likely impossible to make these GPU APIs anonymous, and thus can never really be considered "secure".
Have a nice day, =3
The use cases we initially thought were worth testing out:
https://doc.babylonjs.com/features/featuresDeepDive/webXR
https://doc.babylonjs.com/features/featuresDeepDive/physics/...
https://doc.babylonjs.com/features/featuresDeepDive/mesh/gau...
The goofy game pad use case, and the user level experience: https://doc.babylonjs.com/features/featuresDeepDive/input/ga...
In the end, I culled that project due to simpler inexpensive engine options.
Have a great day, and good luck =3