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

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

Thanks for clarifying, James! I think that makes your position clearer, and I agree with it.

On Tue, Jan 14, 2014 at 4:22 PM, James Darpinian <jdarpinian@google.com> wrote:
On Tue, Jan 14, 2014 at 2:38 PM, Brandon Jones <bajones@google.com> wrote:
Any given feature (including WebGL as a whole) may be viewed in different tiers of support

For many Web APIs it's not just tiers of support, but entirely different APIs for similar features (e.g. Touch Events vs. Pointer Events, Web Audio vs. Audio Data, document.all vs getElementById). In the past these API differences have driven a lot of misuse of the UA string. In WebGL, GL_RENDERER does not suffer from this particular problem. Any given GPU feature has the same API across all GPU vendors.

This means that if a developer wants to use an optional feature, they don't have to write vendor-specific code, and they don't have to switch between two versions of their code for the same feature. You're right that developers can use GL_RENDERER to choose which supported optional features they should use, and that is an important use case. But here again GL_RENDERER is significantly different from UA strings. Browsers change drastically from version to version; performance improvements of 4x or more are commonplace and significant new APIs appear in every release. In contrast, GL_RENDERER describes hardware which can't be changed. GPUs don't get 4x performance boosts or radical new features. Small changes may come in driver updates but most users don't upgrade drivers.

The UA string situation is bad and nobody wants to repeat it. But GL_RENDERER is a completely different situation and the tradeoffs are different.