[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] More WebGL extensions
- To: Chris Marrin <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] More WebGL extensions
- From: Kenneth Russell <email@example.com>
- Date: Tue, 29 Mar 2011 16:29:58 -0700
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301441411; bh=1Eoy3K4Bk5lnX+cOQgMaICpziBw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xCA/MLZ3qKlv2Jc/tHOTUsejVJwV5961ahZkUPfxlSU30iEVx3gtxtsVW7jbH28mt re7nwPqTfeayzGzXHljIw==
- 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=va0GL/RjbtXCqiVEbpeYTCwxHewVUyjDfzvmibyn2MQ=; b=PEWgvxGqS9Ux1XtQUok78IK02PdLYas1DF4s7WeijZd8fOfPCms6qN0DKYSBOb6Rcs 9uE5MhMu61OittSfUfjg==
- 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=J/W2ijWvjwjC/0Fp1oT2EgmdajhizuFPSeUFNJ4X/k/OGNGhuqa+PnpfuY1FyqYEAz ehR2VhGuCcZMCoeFlcXg==
- In-reply-to: <B0240F89-2D65-4666-8598-0DEE31D2BB0F@apple.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <B0240F89-2D65-4666-8598-0DEE31D2BB0F@apple.com>
- Sender: email@example.com
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
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.
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: