[Public WebGL] NPOT (non-power-of-two) textures

Kenneth Russell [email protected]
Fri Jan 15 08:05:59 PST 2010

On Fri, Jan 15, 2010 at 7:29 AM, Chris Marrin <[email protected]> wrote:
> On Jan 14, 2010, at 7:17 PM, Mark Callow wrote:
>> Rectangle texture was a very unfortunate choice of name. The key feature is that the texture coordinates go from 0-w, 0-h instead of 0 to 1.
>> The limited NPOT textures specified in OpenGL ES can be easily implemented on fixed function hardware by padding the textures to the next power-of-2 and scaling the application supplied texture transform so that coordinates 0 to 1 cover the pixels from the original image but not the padding. But with shaders, there is no texture transform. I suppose WebGL could find all the texture access function calls in the supplied shaders. If the sampler parameter corresponds to a texture unit to which a padded texture has been bound, modify the shader to multiply the texture coordinate parameters by the necessary scale. But you would have to switch back to the original shader under the covers, if a non- or differently-padded texture was bound to the texture unit represented by the sampler.
>> Scaling the texture data, as Ken suggests, will cause image distortions when the the texture is non-square which application developers will find unacceptable. The vast majority of NPOT textures will be non-square.
> yeah, I don't think there is any way to support NPOT on hardware that only has Rectangle Texture support other than actually supporting the extension, and that would leave out most if not all embedded hardware. We could make it an optional extension, but I think that moves in the wrong direction. It's not just the name Rectangle Texture that was a mistake, it was the entire feature.
> I feel for Stephen though. Seems like stating that there is still some hardware that has poor performance with NPOT textures might not be a bad idea. But it kind seems like it might send the wrong message. Hmmm.

There could be a separate non-normative section on performance
recommendations or considerations, but this sort of text doesn't
belong in the main portion of the spec.


You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list