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
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
Cedric BAIL