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

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



I think it would be better to ship with just a single format in the
first release of WebGL - we can extend that later - rather than further
delay the 1.0 specification.

But if we ARE going to ship just one format - it had better be 8/8/8/8
because we don't want to force the API to throw away good data on
desktop platforms that support 8/8/8/8 natively.

Could we also specify what is put into the low order bits when the
format is padded?  All Zeroes?  Zeroes in RGB and ones in A?  The high
order bits replicated into the low order bits? (So 0000 => 00000000 and
1111 => 11111111).  It definitely makes a difference...and for
application developers, not knowing is the biggest problem!

  -- Steve


On 11/02/2010 01:29 PM, Kenneth Russell wrote:
> 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: