[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 9:58 AM, Mark Callow <callow.mark@artspark.co.jp> wrote:

If you're going to be snotty, at least make sure you have taken the time to fully understand what the other party wrote. And don't put words in the other party's mouth.
Your statement and mine are wholly unrelated and no part of my statement is untrue.
Your statement makes no sense in that case because:

- For WebGL there can't be an implementation yet because those extensions are not in draft. 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.

- You where also claiming you don't know anybody who implements {half}_linear yet, which is untrue as I have shown, see my previous statement "OES_texture_half_float_linear: supported by 417/1180 devices"
The Khronos ES WG had no such compunction, and that's not what OES means for WebGL anyway.
I was talking about the Khronos ES WG, of which I am a member. The reluctance is real. I don't know how this extension slipped through.
The order of extensions is:

  1. GL_OES_texture_float_linear 
  2. GL_OES_texture_float 

This did not "slip trough". It was introduced as the 35th extension in one bundle. The extensions are now at #149. float_linear was "Ratified by the Khronos BOP, July 22, 2005."
You have had more nearly 8 years to ponder this question. Are you suggesting to withdraw this OES extension from the khronos registry 8 years after it was approved?
"Standard feature" here means a standard feature of OpenGL ES, i.e. available in all implementations.
None of the extensions are "standard features". A standard feature is when the core specification of the API specification declares it a standard feature. That is why they are extensions. 

Don't you realize that your objection creates a massive problem to address the issues with floating point textures? We currently have a problem, that problem needs solving. The solution should not cripple desktops. Seamless fallbacks (to half-precision) exist on mobiles. Desktops do not support half-float textures. Denying float_linear but approving half_float_linear would force UAs to restrict filtering on the only floating point support available on desktops. Is it really your intention to cripple desktop support, break everbodies applications, and force everybody to shunt texturing to a manual implementation of linear interpolation? Really? I'm being snotty because you're arguing to make things massively much worse for everybody while not solving any problem. Please stop that.