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

Re: [Public WebGL] OES_texture_float_linear and OES_texture_half_float_linear extension proposals

On Thu, Mar 7, 2013 at 11:27 AM, Mark Callow <callow.mark@artspark.co.jp> wrote:

- For WebGL there can't be an implementation yet because those extensions are not in draft.
They are in draft and have been for many months.
They are not in draft. http://www.khronos.org/registry/webgl/extensions/ they are in "proposal". Proposal means: "Proposed extensions are intended for discussion on the public WebGL mailing list, in order to move to draft status; they should not be implemented"

Kenneth asked to move them to draft, see the first message of the thread:  "Any comments or objections to moving these to draft status?"
So arguing against an extension in WebGL because it's not implemented, for an extension that's forbidden to be implemented yet. This my friend is circular reasoning, and I wasn't even addressing that part of your statement because it seemed too unlikely you where to want to make this case.
I'm asking if anyone is going to fix their implementations of OES_texture_{half_,}float, if we create the extension. If not, there is not a lot of point wasting further effort.
Nobody can fix their implementations because the extensions are not in draft. If they are in draft, it offers a viable way forward in the following way:

1) Offer up the extensions
2) Start issuing warnings about deprecation on setting filtering mode to linear on floating point textures with the hint to enable the extension
3) Some time later break the feature without the extension being enabled.

Kenneth proposed the extensions, and I'm assuming they thus enjoy the endorsement of the google chrome UA team. I also think they would enjoy the endorsement of Mozilla. Jeff Gilbert or Benoit Jacob could comment on that.

I made no such claim. You really need to read what people write *before* you let your emotions get the better of you. I did claim, and your figures backed it up, that float_linear is not supported on embedded.
Which is true, but it doesn't matter in this case because on mobiles you have a seamless fallback to half float. 

Doh!! Clearly you think I'm an idiot.
No, but you keep mentioning extensions in the same breath as core/standard features. And I keep pointing out how that's obviously not the case. 

The problem is a lot of people who make decisions about which embedded GPU hardware/IP to buy/license for their devices do not understand graphics well and operate from checklists on which anything branded OES has a habit of appearing. This puts pressure on vendors to provide those extensions. For that reason we are, usually, careful about what gets branded OES.

For whatever reason, that decision is past. You *have* branded OES_texture_float_linear as "OES" 8 years ago. You have also stated and I quote: "Of course not" to my question if you where to retire that extension. So from a standards perspective there is no discussion on it anymore. 

Given that almost 8 years have passed, there are still no implementations on any ES 2.0 devices and the functionality has not been included in ES 3.0, one can safely say that it was premature. This passage of time without implementations provides an interesting counterpoint to the previous paragraph which reflects a commonly held belief in the WG.

The presence on mobiles does not matter (because there is the seamless half-float fallback). And even if it did, it doesn't matter because the extension *was* standardized 8 years ago. It isn't going away. Nevertheless, enthusiastic drivers on desktops which do support the OES flavor API, they do include support for that extension.

There are seamless fallbacks for mobiles, but you're trying to create a no-fallback scenario for desktops, which frankly, is simply unacceptable.