As the title states.
Just a simple check for non power of two support (GLEW_ARB_texture_non_power_of_two), to avoid what seems to be a very slow, and very unnecessary gluScaleImage call.
Description
Description
Event Timeline
Comment Actions
alright, I just went over the code and this is indeed the only part that does rescaling.
Thanks for the patch, applied on rev. 42137
Do you know if there is any overhead by actually using nonpow2 textures (even if the gfx supports it)? I'm considering to have this check also in the 2DFilter code, but I don't know if the tradeoff is worthy (basically we run some buffer copy operations and a GLSL shader in a plane that uses the grabbed texture as input.
Actually all the GLSL code in Blender is also doing the scaling for nonpow2 textures.
And from what I (+ Brecht) know, non power of two textures can be a bit slower.
Comment Actions
Thanks for pushing this through.
NPOT (non power of two) textures are slightly slower on the GPU (from what I have been told), and so, in cases where you only need to rescale once, there are potential benefits in doing so.
However, if you need to update the texture at fairly frequent intervals (like streaming in from a webcam, or some other dynamic source), then gluScaleImage becomes obviously slow, and in that case, relying on the built-in NPOT support is much, much faster.
*Note: I am not an expert.