Use queried drawable depth, not the context one.
Fixes grabbing of bitmaps (now using intended colormap) in the
usual 24 bit depth case.
May fix other issues as well(?).
Broken by 3ab9498777 (in v1.11.0).
Patch by Omar Polo:
while upgrading the OpenBSD package I've come across a weird issue.
Due to the order of the flags, the heif module was loading the system'
version of Imlib2_loader.h (in /usr/local/include) instead of the one
from the tarball. This caused failure since the previous version
(1.11.0) didn't had IMLIB_LOADER_INEX.
Tested:
Before:
```
$ IMLIB2_LOADER_PATH=../src/modules/loaders/.libs ./test_load_2
...
[ RUN ] LOAD2.load_1
test_load_2.cpp:121: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
test_load_2.cpp:128: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
test_load_2.cpp:135: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
[ FAILED ] LOAD2.load_1 (70 ms)
...
```
After:
```
$ IMLIB2_LOADER_PATH=../src/modules/loaders/.libs ./test_load_2
...
test_load_2.cpp:122: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
wrong crc file: ./images/icon-64.xpm expected: 4016720483 actual: 671661664
test_load_2.cpp:131: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i]. crc
Which is: 4016720483
wrong crc file: ./images/icon-64.xpm expected: 4016720483 actual: 671661664
test_load_2.cpp:142: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i]. crc
Which is: 4016720483
wrong crc file: ./images/icon-64.xpm expected: 4016720483 actual: 671661664
[ FAILED ] LOAD2.load_1 (69 ms)
...
```
#17:
As per subject, the imlib_clone_image() function no longer preserves
the alpha channel value since imlib2 1.10.0.
This bug report was initially filed by Niko Tyni in Debian's bug tracker.
If you follow the subsequent link you will also find a test program that
demonstrates the regression.
https://bugs.debian.org/1041406
This upstream change is most likely the root cause of the problem
b39d33c800
It looks like an oversight where other functions were adapted
to the new alpha channel implementation, but imlib_clone_image() remains
unchanged and only copies the flags and not the new alpha byte.
During load from file we would do stat(file), then fopen(file),
and assume the stat'ed size corresponds to the fopen'ed file.
However, the file may be changed between stat() and fopen(), which may
cause trouble.
This should now be fixed by always using fstat() on the opened file
descriptor.
When scaling up it worked like there was a 1 pixel border right and
bottom.
This change may affect applications that rely on the old behavior.
Setting the environment variable IMLIB2_LEGACY_SCALING to any value will
make imlib2 use the old algorithm.
When using e16 with the new (default) algorithm a few themes have
incorrectly rendered elements (unintended window border fading, opaque
pager highligt frame, more?).
Hopefully this change should go mostly unnoticed but if it turns out it
causes grief the default will probably have to be changed back.
Now the calculation of ypoints[] and xpoints[] can be done by the same
function and we can avoid some essentially duplicated code.
May be slightly less optimal although I doubt it makes any significant
difference.
Kim Woelders
Chema Gonzalez
Chema Gonzalez
NRK