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

Re: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft



On Fri, Aug 7, 2015 at 11:15 PM, Florian Bösch <pyalot@gmail.com> wrote:
> 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.

Good. I talked with Christophe offline and confirmed the intent of the
getSupportedProfiles function. I've added a non-normative about how
it's intended to be used.

> 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).

This could be done, but I'd be concerned about simply duplicating text
from the KHR extension. For the moment I've just added a strong note
at the beginning to refer to the KHR spec for the behavioral
definitions. Pull requests welcome to reshape the WebGL wrapper
extension.

> 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).

Per above, it seems problematic to duplicate all of the text from the
KHR extension, since that might evolve in which case we'd need to
update the WebGL wrapper. I've left this as is for now.

Since there weren't any objections I've moved the extension to draft status.

-Ken


>
>
> 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.
>>
>> -Ken
>>
>>
>> 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
>> >> >> -----------------------------------------------------------
>> >> >>
>> >> >
>
>

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