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.
avoid dependency on liby4m, which has some quality issues and isn't
available on any distros according to repology.
additionally, the new loader now supports:
* loading from memory
* multi-frame images
* mono colourspace y4m images
Fixes: #13
Seems to be required as of libheif-1.16.
Note - Running the tests with valgrind shows no problems, but with asan
enabled I get a bunch of messages like:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f186d98ee38 in operator new(unsigned long) (/lib64/libasan.so.8+0xd9e38) (BuildId: bac59ca9f1e357781008d7f6982314d30ca62672)
#1 0x7f186c4acec9 in ColorConversionPipeline::init_ops() [clone .part.0] (/lib64/libheif.so.1+0x6fec9) (BuildId: 2823b8c3a24fbf4262672d27ed3bf5a338d185b5)
#2 0x7f186c4a2dec in heif_init (/lib64/libheif.so.1+0x65dec) (BuildId: 2823b8c3a24fbf4262672d27ed3bf5a338d185b5)
#3 0x7f186d824d4e in __imlib_ProduceLoader ../../../../src/lib/loaders.c:209
Kim Woelders
Chema Gonzalez
Chema Gonzalez
NRK