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

Re: [Public WebGL] More WebGL extensions

On Mar 29, 2011, at 4:29 PM, Kenneth Russell wrote:

> On Tue, Mar 29, 2011 at 3:55 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> Following up on the extension discussions this week, I was looking at the WebKit Extensions3D implementation. It supports both extensions that are in the registry and those that are internal implementation details. But two stand out as being useful candidates for the registry:
>>        GL_ANGLE_framebuffer_blit
>>        GL_ANGLE_framebuffer_multisample
>> These were added to the OpenGL ES registry to reconcile the different ways multisampling is done in various imlementations, some standard and some platform dependent. For the display buffer WebGLContextAttributes give control over this feature. But when this extension is available multisampling can be applied to FBOs. I think it's a good candidate because multisampling support is available widely on desktop hardware and on mobile hardware from at least 2 vendors, and is currently deployed on at least one. It also doesn't degrade functionality if not present. It simply reduces rendering quality.
>> I propose we add them to the registry. One issue is that I don't see why this needs to be two extensions. Is there any use for one without the other?
> I think we need to think carefully about which form of the
> multisampling extension we add to the WebGL registry.
> GL_ANGLE_framebuffer_blit [1] requires support for
> framebuffer-to-framebuffer blits. As far as I can tell, the only
> mobile hardware and OS supporting multisampled FBOs is iOS, and the
> form it supports is GL_APPLE_framebuffer_multisample [2], which does
> not have a blit routine, but instead "void
> glResolveMultisampleFramebufferAPPLE(void)".
> This means that if we add the ANGLE versions of this functionality to
> the WebGL extension registry, it will not be implementable even on
> iOS.

Yeah, I suppose I should not have said "add them to the registry" but rather that we should add a multisample framebuffer extension to the registry. I agree that the blit model need not be exposed. I'll write something up when I get a chance

> Also, we would need to specify interactions with OES_texture_float.
> Multisampled floating-point render targets would be extremely useful
> for high quality HDR rendering.

Sure, but that should be yet another extension, since it is possible to support one without the other. 


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