[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Why have readpixels support 5_6_5?
- To: Mark Callow <email@example.com>
- Subject: Re: [Public WebGL] Why have readpixels support 5_6_5?
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Tue, 2 Nov 2010 11:29:05 -0700
- Cc: Tim Johansson <email@example.com>, public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288722548; bh=DIlgbefn5Le5u4lyXYBD2fu6i3c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=kkVRSIw8EdDFfGaRqzks3HEsom9KFGPcmpNNzFHkKOtDH4BoHIoiSPbvtDeykD9OE iJWq9xxJgpXD7pVj12Hag==
- 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=+jz0Q2RJwzqdlG8osBJkdZ8TTbIeGrsCuWr7Q3gfYao=; b=xS7tXYDZU8DKuBHIQ2Cz6JMpsHids3sTp2swtwblemKYzfHb6GXIASwlp5/DXcs6NV OnlQehzqlZrZYBqgigOw==
- 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=RQkKk1WzoFXNcRZKtMUwcZL8FDqP4LVgiW7cF/Xg/NBdVcu2fDyaY0pNyXtPsLxlYg bfEdhuuOoHqsIlnbiNTQ==
- In-reply-to: <4CCFD9E0.email@example.com>
- References: <1200561564.245220.1288642171735.JavaMail.firstname.lastname@example.org> <4CCFD142.email@example.com> <4CCFD9E0.firstname.lastname@example.org>
- Sender: email@example.com
I doubt that any serious incompatibilities would be introduced by
leaving in the support for the implementation color read format and
type, or even having different browsers return different values on the
desktop. Existing OpenGL ES 2.0 apps on mobile devices seem to achieve
That having been said, upon more thought it seems fine to remove it
since RGBA8888 must be supported, and in the spirit of moving the spec
toward completion I think we should do so. Any objections?
On Tue, Nov 2, 2010 at 2:29 AM, Mark Callow <firstname.lastname@example.org> wrote:
> I agree with Tim.
> FWIW the most common implementation read format, when reading from the
> default framebuffer, is RGB565, which is why it was chosen for WebGL. When
> reading from FBOs it is probably whatever format the renderbuffer is, i.e.
> it will be dependent on both application and implementation.
> On 02/11/2010 17:52, Tim Johansson wrote:
> On 2010-11-01 21:09, Vladimir Vukicevic wrote:
> Ah, I didn't realize that it could vary based on the bound framebuffer.
> It was suggested that we fix the type because it was an odd
> implementation-specific variance that wasn't covered by an extension that
> could be queried. But that made sense when we weren't thinking of it as
> framebuffer-specific; since it does vary, then I agree that it doesn't make
> sense to fix it (since most everything with fbos is implementation-dependant
> anyway!). Happy to change them back.
> If we want to change it I would prefer dropping implementation dependent
> read format and either only support RGBA8888 or require software conversion
> to support any format.
> our email:
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: