[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] More WebGL extensions
- To: Chris Marrin <email@example.com>
- Subject: Re: [Public WebGL] More WebGL extensions
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Thu, 31 Mar 2011 12:00:26 -0700
- Cc: public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301598029; bh=lSSIbxrwkRS/EpP3DlICA3sM7uM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=jSGxU8q/i1Mj/Yoa3mvdRLI/TmBu5TbQM2N98q67p/sQ1aLgXRNQGjI+wkUlULPzO 4TWwSK0YwIcdZmiEbMAgA==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HtBRlGMNVT6ZA9XGyV7lk8GTTCPd9Mm1+XsaGiXtGbM=; b=Y5/5jbsIwWh49cByy7aRB9tdH7c+gKso5SPm3hkgJO4MTCpunhFNUVJTlIRv7tBVNi HhXSlJReey9QOyduQ1LA==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y75FFYSHpjNASOF3D14jMh/1N41IODlEGgPE3StQPBo/buQK7YmnBkqYd6Sg1JHIfQ yQenc+3jtzEGkk0Nj9nA==
- In-reply-to: <4ED589C0-5192-4FA9-B1EE-D70BDECEFE35@apple.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <B0240F89-2D65-4666-8598-0DEE31D2BB0F@apple.com> <BANLkTi=BTjSm0pJ-++J9MBAW19XzFwYNMg@mail.gmail.com> <4ED589C0-5192-4FA9-B1EE-D70BDECEFE35@apple.com>
- Sender: firstname.lastname@example.org
On Thu, Mar 31, 2011 at 8:41 AM, Chris Marrin <email@example.com> wrote:
> On Mar 29, 2011, at 4:29 PM, Kenneth Russell wrote:
>> On Tue, Mar 29, 2011 at 3:55 PM, Chris Marrin <firstname.lastname@example.org> 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:
>>> 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  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 , which does
>> not have a blit routine, but instead "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
> 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
That sounds good.
>> 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.
I don't think a third extension is needed. All that's needed is to
specify that if both the OES_texture_float and this multisampling
extension are enabled, then multisampling is enabled for
floating-point renderbuffers (if the implementation supports it -- and
the framebuffer's status will be FRAMEBUFFER_UNSUPPORTED otherwise).
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: