eina_file_mkstemp would return -1 in an error case. Make sure we check
the return when clsoing here.
CID: 1400790
Reviewed-by: Christopher Michael <devilhorns@comcast.net>
Differential Revision: https://phab.enlightenment.org/D11957
ensure that these functions are still usable with async load
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11424
Summary:
when using this property, there should be no mmap loaded after a call
to evas_object_image_file_set, and we want to make sure the image is
eventually loaded
ref T8378
Depends on D11340
Reviewers: raster
Reviewed By: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8378
Differential Revision: https://phab.enlightenment.org/D11341
Summary:
File_Save.save does not work for proxy object from following commit.
c53f152 evas: Make save() work on snapshots
Test Plan:
1. Add an image object and set source object.
evas_object_image_source_set(obj, source);
2. Save the object as a file when you need.
evas_object_image_save(obj, "./file_name.png", NULL, NULL);
Reviewers: cedric, Hermet, jsuya
Reviewed By: Hermet
Subscribers: zmike, subodh6129, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10629
Summary:
this is a clearer name which makes the intent of the API more obvious at
a glance
ref T7875
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7875
Differential Revision: https://phab.enlightenment.org/D9996
Summary:
Coverity reports that we leak variable 'f' going out of scope here, so
if we are going to exit the test, lets close the file before we do
Fixes CID1400945
@fix
Depends on D8770
Reviewers: raster, cedric, zmike, bu5hm4n, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8771
verify that legacy apis function as expected when using legacy api to
load and unload images
Reviewed-by: Hermet Park <hermetpark@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8619
Summary:
verify that legacy apis function as expected when using legacy api to
load and unload images
Depends on D8618
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8619
Summary:
the previous implementation/api had a number of issues:
* "file" property contained both "file" and "key" values
- also performed file loading operation
* "load_error" property which was specific to image objects
* no methods for controlling file loading/unloading
this patch attempts the following changes:
* split "file" property into "file" and "key" properties
- also remove "key" from existing "mmap" property
* remove "load_error"
* directly return error codes from operations
* add "load" and "unload" methods for directly controlling load state
* add implicit file loading if file/mmap is set during construction
* rewrite all efl.file implementations to move file loading into load() method
* rewrite all usage of efl.file api based on these changes
* add C extension functions to mimic previous behavior
ref T7577
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: vitor.sousa, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7577
Differential Revision: https://phab.enlightenment.org/D8018
As cache2 knows cached image could be not matched even though
hash key is not different.
Please refer to the following comment of evas_cache2_image_open.
/* image we found doesn't match what's on disk (stat info wise)
* so dirty the active cache entry so we never find it again. this
* also implicitly guarantees that we only have 1 active copy
* of an image at a given key. we wither find it and keep re-reffing
* it or we dirty it and get it out */
The hash key is created base on the image file address.
If the image file address to find does not equal cached image file address
then it means that the cached image is no longer valid.
This case could happen with the following step.
(1) Call evas_object_image_memfile_set with content data A
(2) Call evas_object_image_memfile_set with content data B
(3) Add timer with short time (ex: 0.01 sec)
(4) Delete A image, and add A image in timer callback
(5) Delete B image, and add B image in timer callback
Sometimes you could see image of A from the B image, because newly created
image at step 5 has same address of setp 1.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D6870
Summary:
jpeg loader tests take 4+ seconds due to manual value comparisons, so ensure
that they run separately
ref T6856
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6856
Differential Revision: https://phab.enlightenment.org/D5911
individual tests should not need to explicitly call init/shutdown functions
in most cases, and many did not properly do this anyway
see followup commit which resolves some issues with eina tests
ref T6813
ref T6811
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
efl_check.h must be included and the EFL_START/END_TEST macros must be
used in place of normal START/END_TEST macros
timing is enabled when TIMING_ENABLED is set
https://phab.enlightenment.org/w/improve_tests/
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
see c8dcc4327b803e9b8ad2a0985e756c924946c442 - basicall evas depends
on ecore these days... thus requires ecore be initted THEN evas. ...
which in theory is an abi break for those using evas and ONLY evas
long ago from when efl was separate... but it''s how we're building
these days.
@fix
Summary:
Summary : String buffer returned by eina_strbuf_new() is not freed in some cases
@Fix
Signed-off-by: Uma Devika <u.bodapati@samsung.com>
Reviewers: cedric, tasn, jpeg, raster, singh.amitesh
Subscribers: tanwar.umesh07, yashu21985, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5000
We set it but never going to use it afterwards. We already tests the
efl_gfx_buffer_colorspace_get() elsewhere in this tests so we can ignore it
for now until we need it and bring it back together with a user.
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
This:
1. opens a file
2. maps its data and vaguely verifies it
3. writes data to it
4. writes data to it with a GRY8 map
5. verifies that the final image has all the proper pixels
Summary:
If you try to load the jpeg image with an orientation mode defined
using elm_photocam, you can see the broken image(in canse of 90 degree)
or even segmentation fault can happen (in case of 180,270 degree)
@fix
Test Plan: photocam menu on elementary_test
Reviewers: Hermet, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2593
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The required precision of decompressed images allows a difference of
1 bit for each pixel compoment [1] . Such difference has been noticed
on OSX when using libjpeg9 from macports.
evas_suite images tests has been modified to compare jpeg images with
this tolerance. Other image formats are still compare with exact
precision
[1] http://en.wikipedia.org/wiki/JPEG#Required_precision
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
currently, normal orientation tests are only added.
I'm going to add flipped orientation tests as well after I put related code in jpeg loader (currently it's not supported)
Reviewers: raster, cedric, jpeg
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D1098
Stefan Schmidt
Mike Blumenkrantz
Shinwoo Kim
Cedric BAIL
Christopher Michael
Marcel Hollerbach
Mike Blumenkrantz
Carsten Haitzler
Jean-Philippe Andre
Vincent Torri
Uma Devika
Cedric BAIL
Tom Hacohen
Stefan Schmidt
Vincent Torri
jiin.moon
kabeer khan
pierre lamot
Wonguk
Daniel Zaoui