Your native VR games need to know how many CPU threads you have to efficiently allocate game processes. Some processes can run at a lower priority, and your OS scheduler figures out the rest.
I can assure you that most of your VR games are using this same data.
But how is my CPU count useful to you in that situation? My i7-8700k has 12 threads, my Surface book 2 pretends to have 16 threads, my iPad Pro pretends to have 16 cores, my iPhone pretends to have 12 cores.
What is the API I can use to map that to any sort of useful 3D performance? How are 3d game processes using this data to evaluate what they are supposed to be doing?
So, considering the amount of responses for thread count that you can not count on for any sort of performance, why do you need the thread count?
Since you already answered downstream, I'll spare you the bother of doing it here...
>You don't need it. I do. blabla, it makes it easier for meblabla native apps are tracking you as well
Do you... Do you maybe not know how concurrency works?
It's not about hitting a minimum threshold of performance. It's about achieving the best possible performance for whatever system it's running on.
Maybe you think because I said VR it must mean I need to be running on massive gaming rigs. We run quite nicely on 5 year old smartphones, too. We run a pancake mode for people without VR. We run on every headset on the market, and we don't have to pay a lick of attention to what Facebook or Google or Apple thinks should and should not be in their app stores. And we can do this because of the broad range of browser APIs.
Maybe you do not know what words in the English language mean? I have a Quest and an Oculus VR and a Samsung Gear VR and a shitty cardboard daydream.
I get how concurrency works. I do not get how you get any sort of useful information from my desktop claiming 12 threads, to my phone claiming 8 threads, to my quest claiming 6 threads, to my ipad/samsung tablet claiming however many threads over webxr.
I do not see how you can do anything useful with the thread count which is what I have been disputing. CPU thread count seems especially useless since it has no relation to VR performance.
I told you what usefulness I get out of it. Any one of those cores can decode a texture in T time. Do you want me to take T*N time to decode them on the render thread, or would you rather I took T*N/C off render thread on a system with C logical cores? I don't care that T is different on different machines. I don't care that C is different. Even small values of C makes up for some very large values of T on old CPUs.
And that is totally fine. If you don't care you don't need to know.
That has been my issue all along. Client computation of course needs to know how many threads are available to distribute computation in an efficient way. Why would the host need to know this though?
>Why does a webpage get to know how many CPU cores I have?
The question we have been replying too? Nobody gives a shit what you can do within the client. Fingerprinting the client as the host is an issue though, you might at least appreciate that...
What is your proposal? Forget the browser for a minute. Just any way, short of airgapping, that a user could receive an app, want that app to perform maximally, but also not have information about the system being egressed?
I don't appreciate it because it's childish. You want to make this out to be a privacy issue when it's not. It adds nothing meaningful to how easily you can be fingerprinted, but removing it would detract significantly from how performant a browser-based application can be made. Without it, you're pushing developers towards having to build native apps instead, giving even MORE access to the hardware fingerprint, where they are now stuck having to pay fealty to the platform gods, while also gaining nothing in reducing fingerprinting in the browser.
I do not dispute that you can use this in your app, my issue is with the server knowing about it (as it is in the demo here) and everything the server can call back from the client. It is not about airgapping but about realizing that current browsers can exfiltrate basically anything.
Your JS app wants to compute the amount of threads it can use on a client, that's great. If your JS app can calculate me switching browsers and using independent websites and their usage, that's cool. Why would you send that back to your server though?
If you do not think that current browser implementations have an issue with the amount of fingerprinting they can do, that is up to you as well. I think that the amount fingerprinting is at the very least difficult though. It is not about building native apps, it is about the amount of information that is send back. Or I'm drunk at this point and should go to sleep, I think I'm done in any case. Sorry about being an ass.
I can assure you that most of your VR games are using this same data.