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

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



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