Thanks for sharing this document ( http://goo.gl/dxRdGS
).
The document does not seem to detail what specific problems are being worked around on "problematic graphics cards". It only mentions taking "corrective action".
What I would really like to understand --- and that is what would affect the most my position on these questions --- is whether there exist broad categories of problems that can be reasonably well detected from the GL strings, and not from other existing WebGL getters.
The document asserts that the Google Maps team has identified such broad issues, and has successfully worked around them by using GL strings. But that information alone is hardly actionable for me, not knowing the underlying data.
I do understand that it would be difficult to share publicly data that would describe some GPUs as "poorly performing". But perhaps you could at least share the data of what categories of issues are being worked around by using GL strings (e.g. "branching in fragment shaders is slow") without embarrassing any particular GPU vendor?
Thanks,
Benoit
On 14-01-13 06:39 PM, Jennifer Maurer wrote:
The document does not seem to detail what specific problems are being worked around on "problematic graphics cards". It only mentions taking "corrective action".
What I would really like to understand --- and that is what would affect the most my position on these questions --- is whether there exist broad categories of problems that can be reasonably well detected from the GL strings, and not from other existing WebGL getters.
The document asserts that the Google Maps team has identified such broad issues, and has successfully worked around them by using GL strings. But that information alone is hardly actionable for me, not knowing the underlying data.
I do understand that it would be difficult to share publicly data that would describe some GPUs as "poorly performing". But perhaps you could at least share the data of what categories of issues are being worked around by using GL strings (e.g. "branching in fragment shaders is slow") without embarrassing any particular GPU vendor?
Thanks,
Benoit
On 14-01-13 06:39 PM, Jennifer Maurer wrote:
The Google Maps and Chrome teams recently conducted an experiment where the GL_RENDERER string was made available via WebGL for 5% of users, so that the performance implications could be quantified. Using this data we have conclusively determined that access to the GL_RENDERER string is required in order to provide a good user experience in the new Maps product, which uses WebGL as its preferred rendering API.
In response, Google Chrome plans to enable access to the WEBGL_debug_renderer_info extension universally, allowing all WebGL applications to access this information. Ideally, we would like all WebGL implementers to follow suit, in order to provide the best user experience for the new Maps and other complex WebGL applications.
In addition, we are petitioning the WebGL working group to remove the security warnings from this and the WEBGL_debug_shaders extensions, as we believe that exposing this information is not as privacy-sensitive as once feared, and the benefits of making it available to real-world WebGL applications have been clearly demonstrated.
Please send feedback on this plan and the proposal for the WebGL extensions to the mailing list.
For further information, please see http://goo.gl/dxRdGS~Jennifer