antville/helma
antville/helma
1
1
Fork 0
Code Issues 5 Pull requests 9 Projects Releases 5 Activity Actions

added a bugfix line for a very weird bug that only occurs from time to time, on some systems:

Browse source 
for more information, read the comments before the following line:
if (i == 0) Integer.toString(alpha);
This commit is contained in:
lehni 2004-08-06 13:09:03 +00:00
parent 23451becef
commit 18d1d5ed60
1 changed files with 15 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

16
src/helma/image/Quantize.java
View file

@ -545,8 +545,22 @@ public class Quantize {
int green = (pixel >> 8) & 0xff; int green = (pixel >> 8) & 0xff;
int blue = (pixel >> 0) & 0xff; int blue = (pixel >> 0) & 0xff;
int alpha = (pixel >> 24) & 0xff; int alpha = (pixel >> 24) & 0xff;
if (alphaToBitmask) if (alphaToBitmask)
alpha = alpha < 0x80 ? 0 : 0xff; alpha = alpha < 128 ? 0 : 0xff;
// this is super weird: on some systems, transparent pixels are
// not calculated correctly if the following block is taken out.
// the bug is very strange, isn't related to the code (compiler error?)
// but doesn't allways happen. as soon as it does, though, it doesn't
// seem to want to go away.
// This happened at various times on my two different debian systems
// and i never found out how to really fix it. the following line seems to
// prevent it from happening, but i wonder wether there's a better way
// to fix it.
// it looks as if the block forces alpha to take on correct values.
// Until now I only knew of effects like that in quantum mechanics...
if (i == 0) Integer.toString(alpha);
if (alpha == 0 && addTransparency) { if (alpha == 0 && addTransparency) {
dst[i] = 0; // transparency color is at 0 dst[i] = 0; // transparency color is at 0