[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Why have readpixels support 5_6_5?
- To: Daniel Koch <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Why have readpixels support 5_6_5?
- From: Kenneth Russell <email@example.com>
- Date: Mon, 1 Nov 2010 12:54:14 -0700
- Cc: Gregg Tavares <firstname.lastname@example.org>, public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288641257; bh=x28WEY/W0LbTt81cjPiqUD6GFWE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=WSczb6/SY3C7xmzdOoh2t/IILLZx4F4lggUKx+heFcFGuTlDrzYr9Ilf9BOrTVAB5 uafQbsXTfVcM3S7lcl+Xg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v931C1VJWGgMlwvgipMCXZbilAPdRs1tbiItgBx+nh8=; b=leR+QUoshuuQ/6gwOAfuY+HNJqMtVdBdrvD4iT+dkSdmVYQgNKf50I6l8KV24wpI/o qF9anMaLNEDE/0AXiLIg==
- 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=GZxMPUCv2ufiCyifCXUKsb34sGVUQeZ82GLlNu2R69FJmxVte7SfQGKqDw0KnKMbvR CuZHZAjzYCBaoqqMVNXQ==
- In-reply-to: <9F2A8AFA-6B7C-492D-9157-49737A42B6A7@transgaming.com>
- References: <AANLkTimLHeg-W5VwAAFTV=ygN20sKq6M0eTc0s+Ua550@mail.gmail.com> <9F2A8AFA-6B7C-492D-9157-49737A42B6A7@transgaming.com>
- Sender: firstname.lastname@example.org
I wasn't particularly happy with the decision at the last WebGL F2F to
specify the implementation color read format and type. Daniel's point
about it being legal to change depending on what precise framebuffer
is bound is a good one. I propose removing the text from the WebGL
spec hardcoding the implementation read format and type.
On Mon, Nov 1, 2010 at 12:04 PM, Daniel Koch <email@example.com> wrote:
> Not that this exactly answers your question, but it is worth noting that the
> GLES2 implementation-defined format is actually framebuffer-dependent, and
> thus may not always be the same.
> Quoting from page 103 of the ES 2.0 spec:
> The values of format and type for this format may be determined by calling
> GetIntegerv with the symbolic constants IMPLEMENTATION_COLOR_READ_FORMAT and
> IMPLEMENTATION_- COLOR_READ_TYPE, respectively. The implementation-chosen
> format may vary depending on the format of the currently bound rendering
> On 2010-11-01, at 1:47 PM, Gregg Tavares (wrk) wrote:
> OpenGL ES 2.0 specifically only allows readpixels to work with 2 formats.
> 1: RGBA / UNSIGNED_BYTE
> 2: Implementation defined RGB or RGBA format
> I'm just guessing but the only reason for the second format is it's the "no
> conversion" path. In other words, if the hardware is rendering to 4_4_4_4
> the second format on that implementation will be RGBA /
> UNSIGNED_SHORT_4_4_4_4 since no conversion = no memory needed + fast.
> WebGL on the other hand is currently speced as requiring the second format
> to be RGB / UNSIGNED_SHORT_5_6_5 so that the second format is consistent
> across browsers.
> The question I have is why even support a second format in WebGL? If the
> only reason for the existence of a second format is to avoid conversion and
> get speed then requiring a specific format in WebGL defeats that goal. A
> WebGL implementation will have to query if 5_6_5 is supported and if not do
> the conversion removing all the speed and memory benefits.
> With that benefit removed why not just change the WebGL spec only support
> RGBA / UNSIGNED_BYTE as a readpixels format?
> Daniel Koch -+- firstname.lastname@example.org
> Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com
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: