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

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



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.

If there is a implementation defined format I'm afraid we will not just ask the underlying GL what the format is and return that. If we do that we might end up not running all content since not all browsers/devices support the same format. What I fear we will instead end up doing for compatibility reasons is to reverse engineer what the most commonly supported read format is in other implementations and always report that (using software conversion if needed).

What makes this issue different from most others IMO is that desktop does not have an implementation read format, so on desktop the WebGL implementations must choose one format it wants to support and the spec does not say anything about how you should choose that format (if we remove the hard coded 565).

I really don't like reverse engineering other implementations in order to make an implementation that works with all content, and writing the spec so you might have to do that is IMO not good.

//Tim

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


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