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

Re: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft

I think the getSupportedProfile function works well and I'm glad we can avoid extension duplication (as the GL and ES registries had to), so that change looks good to me.

Should the generated errors and their reasons be listed in this extension text? It'd probably help with figuring out what you did wrong without having to go read the underlying specification (we have several examples of extensions that list their errors). 

Other than the new errors introduced, a special class of error that would be worth mentioning is what happens if you deliver an image containing blocks in the HDR profile but you only have LDR support. No error is generated if you feed such data in, but any HDR profile block will be pink (note that a file may contain both LDR and HDR blocks at the same time).

On Sat, Aug 8, 2015 at 4:19 AM, Kenneth Russell <kbr@google.com> wrote:
Thanks for pointing that out. I hadn't read the KHR_ or WebGL
extension wrapper carefully. Agreed, it would be technically
infeasible to dynamically enable one profile but not the other. Pull
request up changing the name of the extension and adding profile
support to it: https://github.com/KhronosGroup/WebGL/pull/1146 .
Please comment. Thanks.


On Thu, Aug 6, 2015 at 11:01 PM, Florian Bösch <pyalot@gmail.com> wrote:
> As far as i can see the hdr/ldr difference in terms of api and
> implementation effort should be zero. Hdr differs in internal compression
> format by higher endpoint precision, but this difference is transparent to
> an astc user.
> Both the ldr and hdr extension would return the same extension object,
> effectively these extensions just carry a boolean value between them. This
> boolean value should come straight from the driver.
> What is the reason not to introduce both hdr and ldr at the same time in
> webgl? Both gl and es untroduced them at the same time (the specs even point
> to the same document).
> On Friday, August 7, 2015, Kenneth Russell <kbr@google.com> wrote:
>> Another extension WEBGL_compressed_texture_astc_hdr will be introduced
>> when it's ready. WEBGL_compressed_texture_astc_ldr only covers the low
>> dynamic range profile in
>> https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt
>> -- e.g. the extension string "GL_KHR_texture_compression_astc_ldr".
>> -Ken
>> On Thu, Aug 6, 2015 at 3:55 PM, Florian Bösch <pyalot@gmail.com> wrote:
>> > How's the HDR/LDR profile support going to be differentiated? In OpenGL
>> > this
>> > extension has two name-strings indicating support for both or either of
>> > the
>> > HDR or LDR profiles.
>> >
>> > On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell <kbr@google.com> wrote:
>> >>
>> >>
>> >> I'd like to propose moving
>> >>
>> >>
>> >> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/
>> >> to draft status. This is an important compressed texture format to
>> >> support, and a prototype implementation is being proposed in Chromium
>> >> which we'd like to land. Are there any objections? Comments in
>> >> support?
>> >>
>> >> Thanks,
>> >>
>> >> -Ken
>> >>
>> >> -----------------------------------------------------------
>> >> 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:
>> >> unsubscribe public_webgl
>> >> -----------------------------------------------------------
>> >>
>> >