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

Perhaps. This is the second time we've had an issue like this. We need to pay more attention to what the underlying OpenGL ES specification permits and exactly what new functionality is enabled by a given extension.
The reason this happened is because linear interpolation on desktops on whatever texture format that is supported, isn't even a question.
 
Will implementers provide this extension?
Does not matter.
 
As far as I know nobody has yet implemented {EXT,WEBGL}_color_buffer_{half_,}float which are intended to fix the previous cock-up.
Untrue, OES_texture_half_float_linear is supported 50% of available devices. It is OES_texture_float_linear that is not supported.
 

I am trying to find out why the OES WG created OES_texture_float_linear

Because it also created OES_texture_half_float_linear, and barring the way for anybody wishing to support linear filtering on SUPPORTED texture formats would be extremely foolish.
 

given that (a) no embedded hardware can support it and

They can support it. They don't currently, but that doesn't mean they never wont. Obviously linear filtering for supported texture formats isn't somthing you willy-nilly ignore. 

(b) we are reluctant to brand extensions "OES" unless they can,

The Khronos ES WG had no such compunction, and that's not what OES means for WebGL anyway.
 

and will be, widely supported because the brand leads to the assumption by many customers that the extension is a standard feature.

It *IS* a standard extension. Read that again, "ex-ten-shion". It means it may be available, or it may be not. I have yet to meet anybody who does not understand that.