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

[Mark Callow]

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.

Regards

    -Mark

Kenneth Russell wrote:
> On Thu, Jan 14, 2010 at 12:08 PM, Chris Marrin <cma...@> wrote:
>   
>> ... [snip] ...
>>> A WebGL implementation can scale up NPOT texture data to the next
>>> highest power of two dimension during texImage2D and texSubImage2D
>>> calls. This wouldn't involve any API changes. O3D does this in some
>>> cases as proof that the technique can work without the end user
>>> knowing. I think it would be a bad idea to expose rectangular textures
>>> in the WebGL API; they are definitely not the path forward.
>>>       
>> I'm not sure that works in the presence of shaders. What about the use of
>> textures as shader data? If a shader is using a 100x100 texture as numeric
>> data, scaling that data to 128x128 would break that shader, right? There are
>> also issues with stride and texSubImage2D. Seems like it would at least be
>> very difficult to make it transparent to the user.
>>     
>
> You're correct, assuming the user expected precise sampling using
> NEAREST min/mag filters, rescaling will break the app. However, for
> the majority of use cases this technique can work, and be completely
> hidden from the programmer with enough machinery behind the scenes.
>
> -Ken
>
>   
>> But I agree with you. The other two options are very bad. For now, I will
>> say that this older hardware works with WebGL, it just runs slowly.
>>
>> -----------------------------------------------------------
>> You are currently subscribe to pub...@
>> To unsubscribe, send an email to maj...@ with
>> the following command in the body of your email:
>>
>>
>>     
> -----------------------------------------------------------
> You are currently subscribe to pub...@
> To unsubscribe, send an email to maj...@ with
> the following command in the body of your email:
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100115/fbcfc9a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callow_mark.vcf
Type: text/x-vcard
Size: 398 bytes
Desc: not available
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100115/fbcfc9a5/attachment.vcf>