On Thu, May 8, 2014 at 1:40 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2014-05-08, 8:55 AM, Anne van Kesteren wrote:
>>
>> On Thu, May 8, 2014 at 12:56 PM, Benoit Jacob <jacob.benoi...@gmail.com>
>> wrote:
>>>
>>> WebGL is low-level and generalistic enough that it is not specifically a
>>> "3d" graphics API. I prefer to call it a low-level or generalistic
>>> graphics
>>> API.
>>
>>
>> Fair, forgot about that argument. "webgles" or some such might be
>> better then. Or enshrine "webgl2" forever, but that seems rather
>> weird.
>
>
> One issue which we discussed at the meeting yesterday is how we should
> handle the fact that a version dictionary member would be optional anyway,
> and what the default should be. I think it would be very hard to pick a
> sane default when that is not passed in because of the goal of preventing
> content accidentally working, so I think we might need to end up with
> "webgl" + N forever... :/ Which is not great, but if this ends up being
> the only bad part of the solution, I think I would be happy with it.
Based on what has been discussed in this thread so far, specifically that:
* We expect that UAs and hardware will make these features available
in "chunks" rather than "a feature here and a feature there".
* We want devs to opt in to getting access to new features so that
they don't accidentally depend on a particular "chunk". (FWIW, this
sounds like an awesome thing to me given the hardware dependency
here).
* We expect each new version of WebGL to be fully backwards compatible.
I don't see any particular problems with the
createContext("webgl"/"webgl2"/"webgl3") approach.
A well written page will detect what level is supported and fall back
to older versions as needed.
A poorly written page will just do createContext("webgl2") and not
fall back to webgl1. Whatever we do we can't get such a page to run
properly on a device which doesn't support webgl2, no matter what
syntax we use.
A really poorly written page might do createContext("webgl2") and then
only use the webgl1 feature set. Given the constraint that we want
people to opt-in to additional functionality over the base webgl1
profile, there's always a risk that people will attempt to opt in to
more than they need and then refuse to work when those opt-ins fail.
What bad code patterns is it that people are worried that this
proposal will lead to?
The only thing that I could see which in some sense leads to a
materially simpler API is to simply do createContext("webgl") and ask
developers to do feature detection on the returned context. However
that abandons the opt-in design which I think would be worse.
No matter what, I think the situation here is dramatically different
from CSS quirks mode and JS "use strict". In both those situations
there are backwards incompatible modes. That does not appear to be the
case here.
/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
