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

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



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