when this property is set, the mixin implementation of efl_file_load() is
never called, which means the internal loaded flag (and related data) is
not set, and so the values for these properties must instead be returned
directly from the image data
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11423
Summary:
this was never handled during refactoring because it had already been
removed from the tree by that point
fix T8378
Depends on D11339
Reviewers: raster
Reviewed By: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8378
Differential Revision: https://phab.enlightenment.org/D11340
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:
rename this to match its function
ref T7926, T7875
Depends on D9932
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7926, T7875
Differential Revision: https://phab.enlightenment.org/D9933
in 1 situation at least we delete the eina file (close it) but keep
the ptr around (during destruction) which could cause issues with
callbaks and events on del and so on.... which may lead to multiple
closes where only one should happen ... which would explain my invalid
eina file ref problems i'm seeing. i carefully matched eina file
handle stores/opens/dups to closes in edje/evas and they seemed to all
match up so this audit with comments and fixes seems to have plugged
that now.
@fix
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D8107
Summary:
instead of passing a string which requires reading docs to know which
arbitrary string key=value sets can be passed, use an extensible struct
which contains more easily referenced values
ref T7672
Depends on D8035
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7672
Differential Revision: https://phab.enlightenment.org/D8039
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
Summary:
Eolian adds a per-class BETA guard (like EFL_UI_WIN_BETA) to any method tagged
as @beta. This means that any app (and the EFL code) wanting to use BETA features
has to enable them class by class, which is cumbersome.
This commit replaces the individual guards with the global EFL_BETA_API_SUPPORT
guard, so apps only need to define one symbol to access BETA features.
Any usage of the per-class guards has been removed from the EFL code and examples.
When building EFL the global guard is defined by configure, so all EFL methods
already have access to BETA API.
Efl_Core.h and Efl_Ui.h no longer define EFL_BETA_API_SUPPORT. Apps wanting to
use BETA API have to define this symbol before including any EFL header
(It has been added to the examples requiring it).
Test Plan:
make && make check && make examples still work, but there's a lot less #defines
in the code
Reviewers: zmike, bu5hm4n, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T6788
Differential Revision: https://phab.enlightenment.org/D7924
Summary:
evas_object_image_pixels_dirty_set(img B, False) means
1. app want to mark image object's data is not dirty anymore
2. app don't want to be called get_pixels callback.
that does not mean image need to be redraw.
evas_object_image_pixels_dirty_set(img B, True) means
1. image object's data is dirty, so image object need to be redraw.
2. app want to be called get_pixels callback.
but pixels_dirty_set(img B, FALSE) function also set o->changed to true,
it cause problem related with rendering
Below case is the example of problem.
1. Smart object A
2. Child image object B
3. app call pixels_dirty_set(FALSE) inside pixels_get_callback
pixels_get_callback is called inside the image object B's rendering.
enlightenment's e_comp_object_render do upper job.
After adding preload fetch,
evas_object_image_render_post can call evas_object_change.
https://phab.enlightenment.org/D7157
evas_render_updates_internal
0. enlightenment call evas_object_image_pixels_dirty_set(img B, TRUE)
o->changed = 1;
evas_object_change(img B)
1. smart obj A is in render_objects
2. evas_object_image_render_pre B, o->change=0
3. evas_render_mapped (Smart A)
3-1. evas_render_mapped (img B)
: enlightenment call evas_object_image_pixels_dirty_set(img B, False)
: o->changed=1
3-2. evas_object_change_reset(img B)
4. pending_change(img B)
4-1. evas_object_image_render_post(img B)
o->changed=1 (3-1 step) evas_object_change(img B)->evas_object_change(Smart A)
5. render_post_reset
smart A is chaged(4-1 step), so, called evas_object_change_reset(Smart A)
###smart A is reset(5 step), img B is changed(4-1 step). after this case,
img B never get change to be redraw.
Reviewers: Hermet, cedric, zmike, ManMower
Reviewed By: Hermet
Subscribers: zmike, ManMower, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7821
Summary:
We use this code path for native image hardware planes. Force the
stacking check on those for now so planes don't accidentally occlude
surfaces above them.
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7188
Summary:
Current preloading is too buggy since it's on thread-based.
This is a fundamental improvement to fix a bug.
The critical issue here is,
When preloading img object suddenly cancel its preloading,
the object possibly cannot render image next then because
renderer doesn't have any idea when async cancelling is
finished. Renderer just tries to render regardless of
image loading status, and this could occur no-texture(in gl case)
image object.
So, here improvement is, adding a notification for async cancelled
so that putting img objects to redraw images properly after their preloading is
cancelled.
The best scenario to reproduce this bug is this one.
Evas_Object *img2 = evas_object_image_filled_add(evas);
evas_object_image_file_set(img2, "test.jpg", NULL);
evas_object_image_preload(img2, EINA_FALSE);
evas_object_resize(img2, 200, 200);
evas_object_show(img2);
Evas_Object *img = evas_object_image_filled_add(evas);
evas_object_image_file_set(img, "test.jpg", NULL);
evas_object_image_preload(img, EINA_FALSE);
evas_object_move(img, 200, 200);
evas_object_resize(img, 200, 200);
evas_object_show(img);
evas_object_image_preload(img2, EINA_TRUE);
If you run this on gl backend, occasionally happens rendering fail.
Yet there other bugs on preloading feature....
@fix
Reviewers: #committers, raster
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6919
Summary:
edje_edit_object_add
edje_object_add
emotion_object_add
evas_object_xxx_add
These APIs had allowed to set parent to EFL_CANVAS_OBJECT(Evas_Object) before
8bb11a17. we should call evas_find before safety check for backward compatibility.
Test Plan:
win = elm_win_add(NULL, "main", ELM_WIN_BASIC);
1. `rect = evas_object_rectangle_add(evas_object_evas_get(win));`
2. `rect = evas_object_rectangle_add(win);`
Check that 1. and 2. works.
Reviewers: Hermet, zmike
Reviewed By: Hermet
Subscribers: cedric, #reviewers, CHAN, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6909
In commit 8367f497b8,
type checking code was added for legacy image functions
in order to reduce failing calls of efl_xxx function.
The default return values of some functions for none-legacy
objects (including NULL), however, were not equal to eo-based
default return value, which broke compatibility.
This commit fixes it.
@fix
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
Somehow starting VirtualBox would crash E when trying to upload invalid
data. I believe checking for NULL data here is all we need to do in
order to keep the image data consistent and valid.
I have to admit I'm not 100% sure what is happening here.
Fixes T5868
@fix
evas_object_image_data_get() is a legacy API that I made work
with snapshot objects (evas_object_image_snapshot_set()). Some
changes in the engine broke the behaviour and this patch fixes
it.
When getting the pixels from an FBO, in read-only mode, we need
to create a temporary image (pixels surface) that contains the
copy of the pixels we get from glReadPixels. This image needs
to be deleted afterwards. It is thus stored by the image object
and freed upon _image_data_set() (good) or object deletion (bad).
FBO + read-write is not supported by this API (it is supported
through buffer_map as the filters had to use that).
Fixes T5754
Summary:
When using evas_object_image_data_set(obj, data), if you give the value of data to NULL, the image data is free.
However, Since you have not set a flag in the image object to be modified, it will not be processed in the next render loop.
Eventually, the image data is erased, but you see the image before it was erased.
If evas_object_image_data_update_add() is used to solve this problem, the operation of the function is skipped because the values of w and h in image are 0.
So, If data is NULL, I modified it to call evas_object_change() in evas_object_image_data_set().
Test Plan:
Sample code
{F61599}
{F61601}
Reviewers: Hermet, jiin.moon, eunue, jpeg
Reviewed By: jpeg
Subscribers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4520
to date if you use async preload we still load the header
synchronously and this can be horrible especially with generic
loaders. there is no way to farm this off to the preload thread. now
there is. youhave to set it as a skip head load option before doing a
file_set AND you need to issue a preload ... but now it's possible.
@feature
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
This is to avoid ERR messages such as "object is not an image!"
that can happen when a legacy image function is called on an
eo image (proxy, 3d, ...) object.
Note: This does not fix any known issue, but it's probably a safer
solution.
In elm_image, efl_file_get() was called on a legacy Evas Image
object, which generated an ERR message. This was way too much
noise for something that actually works.
It's best not to call efl_file_get/set API on a legacy
object, but it can be convenient for smooth code transitions
from legacy to pure eo.
Also, add safety to those APIs.
Test case: elm_test genlist dnd, start dragging anything.
This is a better fix than the previous patch, as it keeps
the legacy API check. The point of that check is: if the object
has been created with legacy API (evas_object_image_[filled_]add,
then legacy APIs are allowed, otherwise they are disallowed. This
means only EO APIs should be used on an eo_add() image object.
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.
Summary:
Added flip and orientation interface and used them in evas_image.
Removed efl_image_orientation_set API and used efl_orientation_set and efl_flip_set API.
In implementation part, converted enums back and forth in order to keep current implementation as it is.
Test Plan: src/examples/evas/evas-images5.c
Reviewers: singh.amitesh, raster, tasn, herdsman, woohyun, cedric, felipealmeida, jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3844
Shinwoo Kim
Mike Blumenkrantz
Carsten Haitzler
Mike Blumenkrantz
Xavi Artigas
Jiyoun Park
Derek Foreman
Hermet Park
Yeongjong Lee
Cedric Bail
Jaeun Choi
Daniel Kolesa
Mike Blumenkrantz
Jean-Philippe Andre
Derek Foreman
Jaeyong Hwang
Tom Hacohen
Yeshwanth Reddivari