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

Re: [Public WebGL] Please review WebGL multiple render target extension proposal



The OpenGL ES working group has agreed to move forward with the
extension as EXT_draw_buffers.

The WebGL mirror of the extension has been renamed and finally moved
to draft status. Looking forward to implementations appearing soon.

-Ken


On Wed, Jan 30, 2013 at 1:38 AM, Florian Bösch <pyalot@gmail.com> wrote:
> Any update on the change to the extension?
>
>
> On Fri, Jan 25, 2013 at 7:53 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> Brief update. There has been some good progress, and cross-vendor
>> agreement, on the underlying ES extension spec that
>> WEBGL_multiple_render_targets is based on. Expect another update to
>> the WebGL extension to occur in the next few days, at which it would
>> be a good time to move it to draft status.
>>
>> -Ken
>>
>>
>>
>> On Tue, Jan 22, 2013 at 1:22 PM, Florian Bösch <pyalot@gmail.com> wrote:
>> > Pull request for removal of WEBGL_fbo_color_attachments created
>> > https://github.com/KhronosGroup/WebGL/pull/146
>> >
>> >
>> > On Tue, Jan 22, 2013 at 9:37 PM, Kenneth Russell <kbr@google.com> wrote:
>> >>
>> >> WEBGL_multiple_render_targets is the current proposal.
>> >> WEBGL_fbo_color_attachments didn't implement ES 3.0's semantics, and
>> >> wasn't forward compatible. Please feel free to submit a pull request
>> >> deleting WEBGL_fbo_color_attachments.
>> >>
>> >> Moving WEBGL_multiple_render_targets to draft status is blocked on me
>> >> addressing feedback from TransGaming on the underlying
>> >> ANGLE_multiple_render_targets spec. Sorry for the delay. I will try to
>> >> take care of this in the next day or two.
>> >>
>> >> -Ken
>> >>
>> >>
>> >>
>> >> On Mon, Jan 21, 2013 at 11:05 AM, Florian Bösch <pyalot@gmail.com>
>> >> wrote:
>> >> > There are two MRT extension for WebGL in proposal stage:
>> >> >
>> >> >
>> >> >
>> >> > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_fbo_color_attachments/
>> >> > and
>> >> >
>> >> >
>> >> > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiple_render_targets/
>> >> >
>> >> > Do we need both?
>> >> > Which one(s) can we move to draft?
>> >> >
>> >> >
>> >> > On Wed, Nov 7, 2012 at 6:33 PM, Brandon Jones <bajones@google.com>
>> >> > wrote:
>> >> >>
>> >> >> I know this extension does have WEBGL suffix and so it's relevant,
>> >> >> but
>> >> >> the
>> >> >> whole prefix/suffix thing is a larger conversation affecting
>> >> >> multiple
>> >> >> extensions that's probably worth keeping on it's own thread. I'd
>> >> >> hate
>> >> >> to see
>> >> >> potential issues with this extension overlooked because of all the
>> >> >> *fix
>> >> >> noise. Can we keep this thread focused on the extension proposal?
>> >> >>
>> >> >>
>> >> >> On Wed, Nov 7, 2012 at 7:23 AM, Colin Mackenzie
>> >> >> <sinisterchipmunk@gmail.com> wrote:
>> >> >>>
>> >> >>> >  The next reason to stick to the suffixes is because people
>> >> >>> > already
>> >> >>> > used to C, are used to them
>> >> >>>
>> >> >>> Just for the record, I don't really think this reason holds up IMHO
>> >> >>> because WebGL itself drops the "gl" prefix from function names that
>> >> >>> was
>> >> >>> present in C (and numerous other languages). This decision really
>> >> >>> surprised
>> >> >>> me when I started learning to use WebGL and I think it demonstrated
>> >> >>> a
>> >> >>> willingness to diverge from established conventions where the
>> >> >>> conventions
>> >> >>> themselves have lost their purpose (namespacing). Just my opinion.
>> >> >>>
>> >> >>> Personally, I agree with Florian that the suffixes are mostly
>> >> >>> superfluous, most especially the _WEBGL suffix because from a human
>> >> >>> perspective, we already know it's in reference to WebGL.
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Nov 7, 2012 at 5:50 AM, Florian Bösch <pyalot@gmail.com>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> On Wed, Nov 7, 2012 at 2:36 AM, Jeff Gilbert
>> >> >>>> <jgilbert@mozilla.com>
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>> Original:
>> >> >>>>> glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 16, 16, 0, GL_RGBA,
>> >> >>>>> GL_HALF_FLOAT_OES, nullptr);
>> >> >>>>>
>> >> >>>>> WebGL with vendor decorations:
>> >> >>>>> var ext = gl.getExtension("OES_texture_half_float");
>> >> >>>>> gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 16, 16, 0, gl.RGBA,
>> >> >>>>> ext.HALF_FLOAT_OES, null);
>> >> >>>>>
>> >> >>>>> WebGL without vendor decorations:
>> >> >>>>> var ext = gl.getExtension("texture_half_float");
>> >> >>>>> gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 16, 16, 0, gl.RGBA,
>> >> >>>>> ext.HALF_FLOAT, null);
>> >> >>>>>
>> >> >>>>> Given the documentation we already do for WebGL extensions, I
>> >> >>>>> don't
>> >> >>>>> think the second case has any benefit over the third.
>> >> >>>>
>> >> >>>> It was about the suffixes, not the extension prefixes.
>> >> >>>>
>> >> >>>> The original reason for suffixes was that symbols/constants needed
>> >> >>>> to
>> >> >>>> co-exist within the same flat namespace in C. This reason does no
>> >> >>>> longer
>> >> >>>> exist in WebGL. The next reason to stick to the suffixes is
>> >> >>>> because
>> >> >>>> people
>> >> >>>> already used to C, are used to them and it represents a 1:1 mirror
>> >> >>>> to
>> >> >>>> the
>> >> >>>> existing extensions. This reason really only applies to any suffix
>> >> >>>> but
>> >> >>>> _WEBGL. The last reason to stick to the _WEBGL suffix would be
>> >> >>>> such
>> >> >>>> as not
>> >> >>>> to confuse people who've got some auto-wrapper code that derives
>> >> >>>> the
>> >> >>>> suffix
>> >> >>>> from the prefix, and we wouldn't want them to have to write
>> >> >>>> something
>> >> >>>> like
>> >> >>>> if(extname.match(/.*?_WEBGL$/)){ suffix = ''; } else { suffix =
>> >> >>>> extname.match(/([^_])+$/)[1]; }.
>> >> >>>>
>> >> >>>> I'm not in favor over abolishing prefixes on extension names,
>> >> >>>> mainly,
>> >> >>>> because this turned out to be impossible in a process of painful
>> >> >>>> discovery
>> >> >>>> of heated opinion.
>> >> >>>> I am 100% in favor of not supplying the WEBGL *suffix*, but some
>> >> >>>> would
>> >> >>>> probably not agree.
>> >> >>>> I would be absolutely ok skipping any *suffix* because, they're
>> >> >>>> really
>> >> >>>> superfluous. but more would probably not agree.
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
>> >
>> >
>
>

-----------------------------------------------------------
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
-----------------------------------------------------------