[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

I am also in favor of moving the OES_texture_float_linear extension to draft. I completely agree with Kenneth's conclusions.

Recently I came across a problem with a graphics library I was using for an online photo-editing website. It affected ANGLE and I raised the issue with the Chromium team. See https://code.google.com/p/chromium/issues/detail?id=172278

To solve the issue I had to use TEXTURE_MAG_FILTER and TEXTURE_MIN_FILTER with NEAREST interpolation, which meant pixelated textures. Using LINEAR would have been preferable, but with this the context was rendered completely black.

To have the ability to confirm if the machine can use LINEAR with a OES_texture_float_linear extension check would be extremely useful.


On Thu, Feb 21, 2013 at 8:56 AM, Mark Callow 
<callow.mark@artspark.co.jp (mailto:callow.mark@artspark.co.jp)>
> so I question how supportable OES_texture_float_linear will be outside of desktop implementations

As of Jan 21. 2013 According to http://www.glbenchmark.com/
OES_texture_half_float: supported by 782/1180 devices
OES_texture_float: supported by 733/1180 devices
OES_texture_half_float_linear: supported by 417/1180 devices
OES_texture_float_linear: supported by 0/1180 devices

On Thu, Feb 21, 2013 at 8:56 AM, Mark Callow <callow.mark@artspark.co.jp (mailto:callow.mark@artspark.co.jp)> wrote: 
> 32F textures are not filterable even in OpenGL ES 3.0 so I question how supportable OES_texture_float_linear will be outside of desktop implementations. I do not think we should make a WebGL extension.
> Given the discussion that preceded the decision that 32F textures should not be filterable in ES 3.0 - it greatly increases the size of certain paths in the hardware - I am surprised to see we have an OES extension and I suspect it is not well supported.

This argument is faulty for the following reason.
OES_texture_float is not going away.
OES_texture_half_float is not going away.
OES_texture_half_float_linear is needed to figure out if a half float texture supports linear filtering. You cannot assume linear filtering on half-float will work, roughly half of devices don't support it. Hitherto you have no way of detecting that.
OES_texture_float_linear is needed to figure it out, just like OES_texture_half_float_linear, it is consistent to be able to detect linear filtering support, for the supported floating point formats.

The support for mobiles does not matter to the argument at all, since once you have determined what capabilities you have you will be able to provide a seamless fallback to another format or an alternating renderpath. Witholding the extensions already ratified by khronos for OpenGL ES acomplishes nothing but promote rendering that will not work on mobiles because people are just gonna assume linear filtering works because they have no way to figure out it.

On Thu, Feb 21, 2013 at 8:32 AM, Kenneth Russell <kbr@google.com (mailto:kbr@google.com)> wrote:
> Any comments or objections to moving these to draft status?

I am strongly in favor of moving this extension to draft ASAP.  

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