This looks like a typo: if (animated > 1) when animated is a... Bool!
So, I am not entirely sure why this bug is visible in case of gif
proxies, all it seems that the load_data function may be called
multiple times when the object is visible. So gif close and reopen
happen properly, and the first frame can be decoded.
stable release - cherry-pick me!
the evas gif loader used way too much cpu to decode animated gifs
because in the rewrite that made it correct, it did not store the
current gif file handle and state, thus each frame it would have to
decode all frames before that one before finally decoding the final
one. that means to decode frame 200, it decoded frame 1, 2, 3, 4 etc.
all the way up to 199 THEN decoded 200 on top, so decode cost became
progressively more then further through the animation you were.
this fixes that by storing state and file handle and allowing you to
iterate through.
after several days of beating head on desk, i gave up trying to find
the exact cause of some gifs not rendering right as animated gifs due
to the loader. it had something to do with dispose mode handling and
which frame it was applied to. i noticed the structure made it also
hard to fix, so this re-structures the entire thing with cleaner code,
less code AND more comments, with a limited memory cache (512k) for
previous frames per image (to avoid eating up huge memory blobs for
big/long animations - though at the expense of cpu), and with some
notes for future fixes - like fixing the "load 2 copies of the same
animated gif" issue... that's another day.
this does fix https://phab.enlightenment.org/T443 along with many
other things.
This add finally support for JPEG 2000, but be aware that libopenjpeg
is very badly managed. There is currently only version 1.5.x that does
provide the right files, is usable by a third party and portable. You
can seriously forget any other version.
Evas loaders' open() function expect the key to be a stringshare,
so declare it as such and keep using ref() without add().
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
If a jpeg image is rotated and we have allocated space for ptr_rotate,
then we should free it Always ... Not Only if the degrees are
180...because we allocate it always
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
Because arc doesn't like me much at the moment here's a simple patch to
fix the gif loader for the latest libgif version. DGifOpen now takes a
error param as its final argument, if the param is not NULL it will
return a error code if it fails. Similar to another patch i sent a few
months back. The patch has been tested on OBS for old and new versions.
Goal is to be able to remove all internal Evas call from inside all
loader module. To do so we are going to open and hold a reference to the
file from outside of the module, read the header, create the image data,
load the data, close that reference.
Once that done, the next step is to let the file remain open as soon as
the filename/key is set and add an API to set an Eina_File directly. This
way edje can maintain the same file open as it use for an edje object,
keeping things in sync and avoid rendering glitch during update.
On system like 64bits windows it is not a guaranty that a
sizeof (long) == sizeof (void*), we are better using the right type.
This generate a warning that we could have seen with just cross compilation.
Always returning -1 for the frame duration does not have the desired
effect. Fix the logic checking whether eina_file_open has succeeded.
Animated GIFs play way too fast without this.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 83100