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

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



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


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