W3C home > Mailing lists > Public > public-gpu@w3.org > November 2017

Re: Ill-defined programs

From: Jeff Gilbert <jgilbert@mozilla.com>
Date: Mon, 13 Nov 2017 15:44:51 -0800
Message-ID: <CAOztSJ1pV_Bk_jDk+tW-ut8X6PXhbbCsfQfT16Auy3DyeKT0-w@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Dzmitry Malyshau <dmalyshau@mozilla.com>, public-gpu <public-gpu@w3.org>
First off, those using these APIs (WebGL and WebGPU) are not writing
geocities websites. They are engineers, and we should optimize for
these engineers, not for the layman.

In WebGL, we are aggressive about issuing descriptive errors and
warnings on malformed or questionable API use. We've found this
quickly surfaces portability issues, and makes them very quick to
solve. I anticipate continuing this behavior during implementation of
WebGPU. We have a ton of tools for giving feedback to devs who are
doing the wrong thing, particularly if we have a less-perf-sensitive
debug mode. (which can even be a JS library, not needing to be baked
into the browser)

I think good validation is important for development, but its
performance impact can hurt outside development, once a product is
released. In our usage of APIs inside the browsers, outside of DEBUG
builds, we try to turn off as much validation code as we can, given
its performance impact. If we find it useful to do this, why would web
apps not find it useful to do similar, and be able to run with a
minimum (but not zero!) level of validation?

In the six years I've been a part of WebGL, we have not seen the
divergence in behaviors that you are afraid of, so I'm not sure why
you think they will happen with this new API. Please appreciate our
experience with this field, and the differences it has as compared to
other areas.

On Mon, Nov 13, 2017 at 3:29 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>
>> On Nov 13, 2017, at 3:21 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>>
>> On Mon, Nov 13, 2017 at 12:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> On Nov 13, 2017, at 11:44 AM, Dzmitry Malyshau <dmalyshau@mozilla.com>
>>> wrote:
>>>
>>> Yes. Strong objection. If behavior of any programs is not fully specified,
>>> then web developers will start to accidentally depend on the behavior of one
>>> browser (usually whichever is most popular), and then browsers will have to
>>> reverse-engineer each others' behavior. This has happened so many times in
>>> the course of web standards development that it's almost a running joke.
>>> Every once in a while someone says "hey, let's just not define error
>>> handling, we only need to define the behavior for valid content" it happens.
>>> The first time was HTML, Browsers ended up reverse-engineering each other's
>>> error handling until finally they got sick of the W3C not defining this and
>>> formed the WHATWG to create HTML5, which fully specified parsing behavior
>>> for all invalid documents. CSS, JavaScript and WebAssembly also have fully
>>> interoperable behavior by spec, even in "invalid" or "error" or
>>> "ill-defined" cases.
>>>
>>> Let's not make this rookie mistake. We must fully define the behavior of all
>>> programs.
>>
>> We can fully define it without requiring exact behavior.
>
> I'm not sure what that means. Are you suggesting a menu choice of one of N behaviors? Then the most popular behavior will become a de facto standard.
>
>> It's not a rookie mistake to make compromises here.
>
> It totally is. I can't think of a time we've done this on the web and it has been ok in the long run. I gave you a very notable failure example. Can you cite any past successes for the strategy of sacrificing interoperability on the web?
>
>> There are a variety of ways
>> in which our API here, like WebGL, differs greatly from the parsing
>> deviations in early HTML. It is not white and black. Short of proved
>> code, there will always be accidental portability problems, even if
>> from nothing other than cargo-culting. We should make smart
>> compromises here, using all the tools and avenues available to us,
>> rather than have a knee-jerk requirement for maximum portability.
>> (absolute portability is not even possible with our base graphics
>> APIs)
>
> It's my impression that, historically, graphics programmers have accepted a much lower bar for portability than the standard we strive for on the web. I believe we should shoot for something much closer to the web bar for portability. Accidental portability problems from cargo-culting are exactly the kind of problems I am worried about. The more we create the opportunity for such problems, the more likely that in 5-10 years we'll all have to reverse engineer Chrome for Windows and Safari for iOS behavior for desktop and mobile respectively.
>
> Regards,
> Maciej
>
Received on Monday, 13 November 2017 23:45:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:22 UTC