[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] GL_RENDERER string needed for performant apps



Briefly: Even discounting any privacy concerns, exposure of sniffable information is a very sharp tool. Historically, the web has found sniffing to be harmful. Regardless, most use cases can be covered by a more conservative approach. (gating by user permission) Other needs can largely be solved or ameliorated by other means. Not all requested use cases need to be supported.


There are a number of different use cases brought up in this thread, not all of which *require* unconditional exposure of these strings. I think it would be helpful to address them directly instead of trying to generalize.

Use cases
---------
* Actively collecting statistics for WebGL and organizing by GPU. (WebGL stats, etc.)
* Letting a user submit a 'something's wrong/slow' bug, and having info on what hardware it is.
These don't require unconditional exposure. This can be gated behind a user-accepted doorhanger/permission dialog.
Notably, something similar to Valve's hardware survey would work fine with this mechanism.


* Use the driver/gpu info to estimate performance.
This can be accomplished by getting permission from the user to query this info the first time, then stored.
I would go further, and say this is a much softer requirement than most people believe. Most every game from Flash up to triple-a titles have a long history of letting the user manually select a quality (performance) level. 


* Driver X doesn't handle Y properly, so we want to do something different for driver X.
In an emergency, just work around it unconditionally, if possible. (generally possible)
File a bug!

Notably, we've had numerous instances in the past where developers think a driver is buggy, but it's actually spec compliant, and the devs were relying on non-spec assumptions which held steady for only *some* drivers.

Assuming, however, a real issue, this is ideally the browser's job to handle: We're supposed to be offering a consistent API. This is huge, saving everyone else time and money. The pragmatic issue is that it takes more time to ship workarounds to users via the browser than just pushing a patch fix to production.

Selfishly, I'd love it if somehow people were forced to bother us if they hit a driver bug, and it would probably even make the web better for having been reported. (though this is clearly not a good motivation to force compliance by this mechanism) I have discovered the presence of a number of bugs only by overhearing grumbling about them. (Please report bugs! Or at least email us about them)


Other notes
-----------
It has been suggested that community disapproval at 'bad' usages of sniffing should help prevent such usages. This does not align with what we've seen on the web historically or recently. I think that working around sniffing by spoofing is not a good suggestion, and does not provide a good solution.

I question whether Google Maps's experience is very typical of what larger apps and games should expect. It is my understanding that the fallback from WebGL to canvas not because canvas is itself faster, but rather because the non-WebGL version is much simpler and less capable. (please correct me if this is wrong!) With the exception of 'majorPerformanceCaveat', I believe that WebGL should always have a higher performance ceiling than canvas or DOM, where available. Browsers are currently working to back their canvas2d implementations with OpenGL, and many have already backed DOM 'graphics' with GPU acceleration. Since this is a naive translation of incoming canvas2d commands or DOM manipulations, the resulting performance should be strictly worse than a purpose-built WebGL backend.

There are a number of projects (both in-development and hitting the market) that represent sophisticated use cases of WebGL, but have apparently not had the same issues as those we've heard about from the Maps team. By this I don't mean to discount the issues Maps encountered, but rather I suspect their use cases are much more unique than they have been presented as. I'm currently asking around about any similar issues our partners might have encountered, but from my work on a couple port projects, not once did requests for RENDERER or VENDOR string access come up around me.


I think having it gated behind a permission request would solve all major issues. I was supposed to draft this proposal (apologies!), but have not yet found the time. Further, I believe that generally, RENDERER/VENDOR strings are less useful that the Maps team's experiences would indicate. I am primarily convinced of the usefulness of these strings for the use cases of *active* WebGL stat collection, and collection of debugging and support info for apps with the permission of the user. I am not convinced that unconditional exposure of these strings is a strict requirement for performant apps.

-Jeff

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------