Created attachment 96745 [details]
Example image (with mipmaps), the height of which triggers the problem
There seems to be a problem with some compressed textures. When the height =
of
the image (more specifically, of the mipmap level used) is not a multiple o=
f 4,
it appears that the bottom part of the image =E2=80=93 as rendered =E2=80=
=93 contains random
junk, apparently set at image load time.
The example image will show the problem at its original size. I've also pla=
yed
with its height (initially 570px): increasing it to a multiple of 4 would
remove the problem if it's rendered using the full-size version, but since =
when
reduced by one level the height is again not a multiple of 4, the problem
re-appears. Setting the full-size height to 576px moves the problem down
further.
(We're using http://cru=
nch.googlecode.com/svn/trunk/ for image
(de)compression.)