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

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



On Tue, Nov 6, 2012 at 7:40 AM, Kenneth Russell <kbr@google.com> wrote:
> A central tenet of WebGL is that it doesn't arbitrarily diverge from
> the OpenGL rules. If this change were made, then it could be argued
> that all of the other WebGL extensions like
> EXT_texture_filter_anisotropic, OES_standard_derivatives, etc. would
> drop the suffixes from the enums they expose.
> I don't think this is a
> good idea so am leaving the naming convention as it stands.

I have no issue using suffixes from native EXT or OES when they already exist.
Indeed, staying as close as OpenGL as possible is one of the great
feature of WebGL.
But I'm not sure to agree this is a case of diverging from OpenGL here
as we are not reusing an existing 'MRT all-in-one' native extension
here - and our extension system is already divergent per-design
anyways.

Also, WEBGL_debug_shaders, which is the first and only approved
WEBGL_* extension to introduce a function signature, already does not
follow this as it declares getTranslatedShaderSource, not
getTranslatedShaderSourceWEBGL.


> cleanup will give us all something to look forward to when the OpenGL
> ES 3.0 functionality is folded in to the core WebGL spec.

Cleaning up the names now will allow developers to access MRT-related
enums and functions in a backward compatible way on both WebGL ES 2.0
and WebGL ES 3.0 contexts using something as simple as "glmrt =
gl.drawBuffers ? gl : gl.getExtension("WEBGL_MRT");".


Either way, I still think we should take the opportunity of clarifying
now that WEBGL_ extensions do or do not not need suffixes while we
still haven't clearly moved in one direction or another (the currently
approved WEBGL extensions are in an unfortunate 50/50 situation - one
with two _WEBGL-suffixed enums, the other with no suffix on an
function signature).


Thoughts?


>
> -Ken
>
>
> On Sun, Nov 4, 2012 at 8:32 PM, Brandon Jones <bajones@google.com> wrote:
>> Most extensions use postfixes, they're just normally OES, EXT, etc. I'm not
>> sure why WEBGL would be a special case.
>>
>>
>> On Sun, Nov 4, 2012 at 8:00 PM, Cedric Vivier <cedricv@neonux.com> wrote:
>>>
>>> On Sat, Nov 3, 2012 at 11:05 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>> > That awkward moment you realize you've been doing something annoying but
>>> > you
>>> > keep on doing it because it would be silly to stop now. I can tell you
>>> > all
>>> > about it :)
>>>
>>> IIRC we have only one 'approved' extension using the WEBGL postfix
>>> enums right now : WEBGL_debug_renderer_info, a somewhat minor and very
>>> webgl-specific one that is.
>>> So it is imho something we could and should fix now before promoting
>>> any new extension to draft or 'approved' status.
>>>
>>> Regards,
>>>
>>>
>>> >
>>> >
>>> > On Sat, Nov 3, 2012 at 3:59 PM, Brandon Jones <bajones@google.com>
>>> > wrote:
>>> >> I'm not sure what the reasoning is behind the WEBGL postfix, but I
>>> >> agree
>>> >> with Cedric: it does lend a somewhat clunky feel to the function calls.
>>> >> I
>>> >> wouldn't be sad to see them go.
>>> >>
>>> >> Of course, this isn't the only extension that does this
>>> >> (OES_vertex_array_object postfixes all of its functions as well) so it
>>> >> may
>>> >> be even more awkward to stop doing it now.
>>> >>
>>> >> On Nov 3, 2012 12:07 AM, "Cedric Vivier" <cedricv@neonux.com> wrote:
>>> >>>
>>> >>>
>>> >>> On Sat, Nov 3, 2012 at 4:07 AM, Kenneth Russell <kbr@google.com>
>>> >>> wrote:
>>> >>> > Are there any objections to moving the WebGL MRT extension spec from
>>> >>> > "proposed" to "draft" status? This would enable prefixed prototypes
>>> >>> > (i.e., MOZ_WEBGL_multiple_render_targets,
>>> >>> > WEBKIT_WEBGL_multiple_render_targets).
>>> >>>
>>> >>> There is a minor typo for DrawBuffersWEBGL, it should start with a
>>> >>> lowercase "d".
>>> >>> Other than this, what do you think of getting get rid of the _WEBGL
>>> >>> suffixes everywhere?
>>> >>>
>>> >>> In WebGL, namespacing is already handled through the WebGL extension
>>> >>> object, therefore the suffixes are unnecessary and makes the API feel
>>> >>> quite verbose/alien imho.
>>> >>>
>>> >>> Additional benefit is that it simplifies porting and
>>> >>> backward-compatibility shims whenever we have ES 3.0 support directly
>>> >>> in the core API.
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> >
>>> >>> > Even though the underlying ANGLE extension still needs to be
>>> >>> > thoroughly reviewed by TransGaming, I don't anticipate major
>>> >>> > changes.
>>> >>> > It merely pulls the OpenGL ES 3.0 semantics for MRTs back to OpenGL
>>> >>> > ES
>>> >>> > 2.0. The only potential issue I can think of is that two extensions
>>> >>> > (fbo_color_attachments and draw_buffers) were merged into one, and
>>> >>> > the
>>> >>> > extension name exposed to GLSL was changed; if this turns out to be
>>> >>> > a
>>> >>> > problem for some reason, then the extension might need to be split
>>> >>> > up.
>>> >>> >
>>> >>> > -Ken
>>> >>> >
>>> >>> >
>>> >>> > On Wed, Oct 17, 2012 at 11:45 AM, Kenneth Russell <kbr@google.com>
>>> >>> > wrote:
>>> >>> >> Yes.
>>> >>> >>
>>> >>> >>
>>> >>> >> On Wed, Oct 17, 2012 at 11:25 AM, Florian Bösch <pyalot@gmail.com>
>>> >>> >> wrote:
>>> >>> >>> Right, so the idea's to introduce FP-textures properly a second
>>> >>> >>> time
>>> >>> >>> around
>>> >>> >>> which would modify the framebuffer/mrt extensions clamping
>>> >>> >>> behavior?
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> On Wed, Oct 17, 2012 at 8:14 PM, Kenneth Russell <kbr@google.com>
>>> >>> >>> wrote:
>>> >>> >>>>
>>> >>> >>>> Ah, sorry, pulled the trigger too quickly on that email. I see
>>> >>> >>>> the
>>> >>> >>>> section you're pointing out.
>>> >>> >>>>
>>> >>> >>>> It's been pointed out most vehemently by Mark Callow that I in
>>> >>> >>>> particular glossed over the subtleties of floating-point render
>>> >>> >>>> targets when adding optional support for them in the WebGL
>>> >>> >>>> exposure
>>> >>> >>>> of
>>> >>> >>>> OES_texture_float. There is an ongoing discussion about the
>>> >>> >>>> correctness of the OES_texture_float conformance test as well
>>> >>> >>>> (http://www.khronos.org/bugzilla/show_bug.cgi?id=729).
>>> >>> >>>>
>>> >>> >>>> Another OpenGL ES extension proposal should be coming soon which
>>> >>> >>>> supports floating-point render targets more thoroughly than
>>> >>> >>>> WebGL's
>>> >>> >>>> exposure of OES_texture_float, and I think that rather than try
>>> >>> >>>> to
>>> >>> >>>> patch up the existing specs we should just wait for that one to
>>> >>> >>>> come
>>> >>> >>>> along and then point to it. From the standpoint of the MRT
>>> >>> >>>> extension,
>>> >>> >>>> OES_texture_float should be considered to affect individual color
>>> >>> >>>> attachments in the same way that it affects the previous single
>>> >>> >>>> color
>>> >>> >>>> attachment to FBOs. I wouldn't want to do a half-baked job again
>>> >>> >>>> trying to add FP render target support to this MRT extension so
>>> >>> >>>> again
>>> >>> >>>> let's wait for the new extension.
>>> >>> >>>>
>>> >>> >>>> The vast majority of ES 2.0 hardware will not support
>>> >>> >>>> floating-point
>>> >>> >>>> render targets, but my hope is that some or most ES 3.0 hardware
>>> >>> >>>> will.
>>> >>> >>>>
>>> >>> >>>> -Ken
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>> On Wed, Oct 17, 2012 at 11:04 AM, Kenneth Russell
>>> >>> >>>> <kbr@google.com>
>>> >>> >>>> wrote:
>>> >>> >>>> > This is pretty much an orthogonal question to the MRT proposal.
>>> >>> >>>> > Please
>>> >>> >>>> > start a new thread for it.
>>> >>> >>>> >
>>> >>> >>>> > -Ken
>>> >>> >>>> >
>>> >>> >>>> >
>>> >>> >>>> > On Wed, Oct 17, 2012 at 2:11 AM, Florian Bösch
>>> >>> >>>> > <pyalot@gmail.com>
>>> >>> >>>> > wrote:
>>> >>> >>>> >> I think that's fine. I've got one question though. I know that
>>> >>> >>>> >> when I
>>> >>> >>>> >> attach
>>> >>> >>>> >> a floating point texture, that the output values are not
>>> >>> >>>> >> clamped
>>> >>> >>>> >> to
>>> >>> >>>> >> 0-1. I
>>> >>> >>>> >> also know that the OpenGL ES 2.0 specification states the
>>> >>> >>>> >> clamping as
>>> >>> >>>> >> behavior (which is also mentioned in this extension). I'm not
>>> >>> >>>> >> sure, but
>>> >>> >>>> >> I
>>> >>> >>>> >> think the desktop versions of OpenGL don't specify the
>>> >>> >>>> >> clamping
>>> >>> >>>> >> at the
>>> >>> >>>> >> shader output level (there's some function to control
>>> >>> >>>> >> clamping).
>>> >>> >>>> >>
>>> >>> >>>> >> I'm a bit worried that this might be a behavioral difference
>>> >>> >>>> >> between
>>> >>> >>>> >> Mobiles/Desktops that could shoot you in the foot if/when you
>>> >>> >>>> >> find a
>>> >>> >>>> >> mobile
>>> >>> >>>> >> with floating point texture render target support. Anybody
>>> >>> >>>> >> know
>>> >>> >>>> >> if
>>> >>> >>>> >> mobiles
>>> >>> >>>> >> do the clamping regardless of target format?
>>> >>> >>>> >>
>>> >>> >>>> >> On Wed, Oct 17, 2012 at 3:51 AM, Kenneth Russell
>>> >>> >>>> >> <kbr@google.com>
>>> >>> >>>> >> wrote:
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>> Please review an extension proposal adding multiple render
>>> >>> >>>> >>> target
>>> >>> >>>> >>> functionality to WebGL:
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiple_render_targets/
>>> >>> >>>> >>>
>>> >>> >>>> >>> It mirrors a proposed extension for ANGLE which adds this
>>> >>> >>>> >>> functionality to OpenGL ES 2.0:
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>>
>>> >>> >>>> >>> https://angleproject.googlecode.com/svn/trunk/extensions/ANGLE_multiple_render_targets.txt
>>> >>> >>>> >>>
>>> >>> >>>> >>> Please provide your feedback on both.
>>> >>> >>>> >>>
>>> >>> >>>> >>> Apologies for how long it took to produce these extensions.
>>> >>> >>>> >>> They
>>> >>> >>>> >>> couldn't be drafted until OpenGL ES 3.0 was released, because
>>> >>> >>>> >>> in
>>> >>> >>>> >>> order
>>> >>> >>>> >>> to avoid compatibility issues in the future, it was necessary
>>> >>> >>>> >>> to
>>> >>> >>>> >>> derive their contents from the ES 3.0 specification. The
>>> >>> >>>> >>> draft
>>> >>> >>>> >>> ANGLE
>>> >>> >>>> >>> extension modifies the same areas of the OpenGL ES 2.0
>>> >>> >>>> >>> specification
>>> >>> >>>> >>> modified by the GL_NV_fbo_color_attachments and
>>> >>> >>>> >>> GL_NV_draw_buffers
>>> >>> >>>> >>> extensions, but draws the majority of its text and semantics
>>> >>> >>>> >>> from the
>>> >>> >>>> >>> ES 3.0 spec.
>>> >>> >>>> >>>
>>> >>> >>>> >>> -Ken
>>> >>> >>>> >>>
>>> >>> >>>> >>> -----------------------------------------------------------
>>> >>> >>>> >>> 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
>>> >>> >>>> >>> -----------------------------------------------------------
>>> >>> >>>> >>>
>>> >>> >>>> >>
>>> >>> >>>
>>> >>> >>>
>>> >>> >
>>> >>> > -----------------------------------------------------------
>>> >>> > 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
>>> >>> > -----------------------------------------------------------
>>> >>> >
>>> >>>
>>> >>> -----------------------------------------------------------
>>> >>> 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
>>> >>> -----------------------------------------------------------
>>> >>>
>>> >
>>
>>

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