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

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



IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE
have been removed from the WebGL spec and IDL, and the section on
differences from OpenGL ES 2.0 updated.

-Ken

On Tue, Nov 2, 2010 at 11:37 AM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
> To removing it outright, and leaving RGBA8888 as the only readpixels format?  Not from me.  I can't think of a situation where 565 readback would be a performance win (for feeding to anything else on the Web API side).
>
>    - Vlad
>
> ----- Original Message -----
>> 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
>> good portability.
>>
>> 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?
>>
>> -Ken
>>
>> On Tue, Nov 2, 2010 at 2:29 AM, Mark Callow <callow_mark@hicorp.co.jp>
>> 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.
>> >
>> > Regards
>> >
>> > -Mark
>> >
>> > 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 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: