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

Re: [Public WebGL] specification/implementation cadence

It takes time to mature a spec after conception. In retrospect, WebGL1
really wasn't ready to go when it was released. In the gap between
WebGL1 and 2, we not only worked on WebGL2, but also invested a huge
amount in making WebGL1 the impressively performant, stable,
consistent, and portable API it is today.

But it didn't take as long as you say, relatively speaking. GLES2 and
3 was 2007 and 2012 respectively. GLES 3.1 was two years later in
2014, and GLES 3.2 (which largely just brings AEP into core) was 2015.

You can roughly pretend that our WebGL 1.1 was our body of extensions,
circa 2014. This brings our cadence up to about par.

That said, I expect things to move faster now that we have our feet
underneath us better with regards to WebGL performance and stability,
and WebGL2 is almost gold.

On Tue, Aug 9, 2016 at 3:59 AM, Florian Bösch <pyalot@gmail.com> wrote:
> I'd like to comment on some comments made in relation to future planning.
> The blow comment was by brandon a year ago (august 2015)
> On Mon, Aug 31, 2015 at 2:44 AM, Brandon Jones <bajones@google.com> wrote:
>> We're too deep into WebGL 2 to be distracted much with what WebGL Next
>> looks like,
>> Avoiding that work in favor of focusing on a next gen API would be doing
>> the WebGL community a huge disservice.
> The following comment was made 4 days ago also by Brandon:
> On Fri, Aug 5, 2016 at 7:09 PM, Brandon Jones <bajones@google.com> wrote:
>>  I'd also be fine with something completely new, though I don't think the
>> WebGL working group has the time, energy, or manpower for it.
> This comment was made by Jeff yesterday:
> On Mon, Aug 8, 2016 at 9:27 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>> However, as a working group, we don't have bandwidth to even have
>> effective debates on this right now. WebGL 2 must ship. I expect we'll get
>> back around to WebGL-next later this year.
>> As such, I caution against investing work in designing anything ahead of
>> the WG's availability.
> In various other discussions between 2012 and today this topic has come up:
> Let's drop everything and concentrate on WebGL 2, it being variously applied
> against WebGL 2.1, WebGL-next and extensions (of WebGL 1).
> I don't think it's a good strategy to drop all future planning and
> specification work until one implementation has been finished (and not just
> specified, but also fully implemented).
> There's probably too few people to simultaneously do specification work and
> implementation on the WG. But it isn't like this for any other standard and
> vendor group.
> OpenGL has been specified at a cadence of 1-2 revisions of the API per year
> since OpenGL 3.0. It usually took vendors around half to a year to provide
> implementations, which means that at any point in time 1-2 OpenGL revisions
> where in spec phase and 1-2 implementations where in development by each
> vendor. Much the same is true for OpenGL ES.
> WebGL 1 (which is the only currently usable version) is out of date by
> nearly 10 years, and WebGL 2 is out of date by nearly 5. It seems that while
> other standard bodies manage to output implementations and specs at a
> cadence of 1-2 per year, it takes the Web 5 years on average to advance by
> one.
> Projecting this out to the future does scare me:
> WebGL 2.1: 2022 (7 years out of date)
> WebGL 2.2: 2027 (12 years out of date)
> WebGL 2.3: 2032 (probably 15 years out of date)
> WebGL-Next 1: 2037 (21 years out of date)
> It's clear to me something has to change drastically on this trajectory. And
> the perpetual "Let's concentrate on the next thing" mantra doesn't seem to
> be working all that well (WebGL 2 was supposed to be available way sooner
> than end of this year).
> I do appreciate that things do take time, but it just doesn't seem to me
> that pushing the next thing out till the last one has finished, is working
> out so great. The cycle usually is:
> Do A
> Don't plan B thing because A is soon finished
> A is delayed, putting strain on everybody
> Goto A
> Seems to me to be a fairly well documented case of Waterfall planning
> breakdown and chronic resource shortage.

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