regression introduce in c08ae5f. if the color space was the last thing
in the header than it would be followed by a newline rather than space.
peek to ensure next char is either ' ' or newline to avoid falsly
matching problematic colorspaces. this will also work for other cases
like "mono-whatever" instead of working just for "420", "422" and "444".
also change the return code to unsupported instead of corrupted in these
png_write_end may trigger a write error which sets off longjmp - which
then goes ahead and tries to free `misc.data` again. move the
png_write_end call before `quit` label to avoid this.
to reproduce, build scrot and imlib2 with ASan and then try to save a
screenshot to /dev/full (`scrot -o /dev/full`).
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.
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.
This upstream change is most likely the root cause of the problem
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
This should now be fixed by always using fstat() on the opened file
When scaling up it worked like there was a 1 pixel border right and
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