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

Re: [Public WebGL] Why have readpixels support 5_6_5?



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.

    - Vlad

----- Original Message -----
> 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.
> 
> -Ken
> 
> On Mon, Nov 1, 2010 at 12:04 PM, Daniel Koch <daniel@transgaming.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
> > surface.
> > Daniel
> > 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 -+- daniel@transgaming.com
> > Senior Graphics Architect -+- TransGaming Inc. -+-
> > www.transgaming.com
> >
> 
> -----------------------------------------------------------
> 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:

-----------------------------------------------------------
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: