I'm trying to fix a crash that seems to happens in some very odd
circumstances under stress testing. I have absolutely no idea
what is going wrong... So let's just add some extra safety.
Summary:
When Evas is deleted the function _evas_device_cleanup() goes thru all
devices and unref them. Since Evas_Devices are Efl_Input_Device, the user
may still hold a reference to the device (efl_ref()),
thus causing the device to do not be deleted *yet*.
This causes a problem, because when the user calls efl_unref()
and the device itself is deleted the Evas _del_cb
callback will be called and will try to access the Evas_Public_Data from
a deleted object.
In order to avoid this problem all devices will be kept in the devices
list and Evas will unregister the EFL_EVENT_DEL from those devices that
were not deleted.
Reviewers: jpeg, bdilly, barbieri, cedric
Reviewed By: bdilly, cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4369
so since this uses new pos - cur pos to move BY x pixels... there is
an issue that if the move of the obj ends up re-moving the current obj
TO the same pos. it moved BY the same delta again thus racing ahead.
not great. because x/y is not stored until the call stack returns to
after the smart move func and the pos set storce the new position in
the object struct. the easiest way atm until we have relative
positioning etc. is to store this in the smart obj and use the delta
at that time of the call then store it immediately so a recursion ends
up with a delta of 0 if its the same pos, so go back to where we were.
this fixes a nasty issue i spotted in fileselector that made filesel
icons race along when scrolling 2x as fast as everything else. oddly i
couldnt see this in any other widget that scrolled when i looked...
which is odd, but... either way a nasty issue... subtle... and now
fixed. never saw this before so this seems new.
In case of a mapped object (eg. when applying a map to a window
in wayland compositor), the canvas and output coordinates are
not meant to be the same.
In EO land, applications should instead use the common interface
Efl.Input.Interface.pointer_xy.get (on the canvas).
@fix
This patch fixes an issue where border icons were missing when running
EFL Wayland client applications. This also fixes the issue where
softcursor mouse pointers would not draw over bottom window border.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
before changing MAGIC_CHECK to eo_isa passing NULL to a function would
result in nothing, now it gives a error message. This restores the old
behaviour.
Due to commit 7ce79be1a1, EFL Wayland
Client applications stopped rendering their window icons. This was due
to the code which tried to detect if an object is in framespace.
Previous version would just check the obj->is_frame flag ... which is
insufficient to determine if an object is in Framespace. This commit
fixes that issue by checking an objects geometry also.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This was broken for smart objects that are not "clipped smart
objects". This fixes the example evas_smart_object.
NOTE: This EAPI was removed in efl-1.18!
/!\ This was an uncaught API break between 1.17 and 1.18 /!\
@fix
Coverity reports this as a dereference before null check which implies
that 'cur' May be null here, so let's not use it before we check it.
Fixes CID1363765
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports this as a dereference before null check which implies
that 'pd' May be null here, so let's not use it before we check it.
Fixes CID1364114
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch fixes Coverity CID1364123 which reports that (in some
cases) va_end was not being called for var args. As they were
previously initialized with va_start, then va_end should be getting
called.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Lacking a proper internal tag, I'm using both protected (it is
in fact a protected access function) and beta (to mark as unstable,
not real API).
New smart objects based on EO only should rely on constructor,
finalize and destructor exclusively. In theory, this should be fine.
Unfortunately it may be impossible to inherit from the Efl.Ui.Win
class as it uses a really bad hack and calls super.constructor
inside the finalize method.
This is an override of efl_gfx_size_set. Same as before, the
order of operations matter so it is possible that a corner
case will break. In particular, legacy code was:
- intercept
- smart resize (do stuff), super, super, super
- evas object resize
The new code is more like:
- intercept
- super, super, super, evas object resize
- do stuff
But unfortunately this broke elm_widget (read: all widgets) as
the internal resize was done before the object resize. So,
inside the resize event cb, the resize_obj size would not match
the smart object size. >_<
This is an override of efl_gfx_position_set.
As for the other patches, I hope I didn't break anything.
A problem likely to happen is that the super call was inserted
too early or too late in the call flow. For instance:
_myclass_position_set(obj, x, y) {
position_set(super(obj), x, y);
position_get(obj, &prevx, &prevy);
do_something_with_delta_xy();
}
The above code flow is obvisouly wrong, but may have crept in this
patch (such a bug sneaked in inside smart object, breaking
everything at first).
While this kind of API seems to make sense with smart objects
(relative coordinates), it is currently not used apart from
the smart object class itself.
So, for now, I'm moving this to legacy to clean up Efl.Canvas.Group
and we can later add the equivalent in a clean "group" API.
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
Similarly to group_color_set, group_clip_[un]set should not
exist and should be a result of efl_super and inheritance.
This patch also removes clip_unset from the EO API and keeps
only clip_set(NULL). The reason is that it will avoid bad overrides
of clip_unset() vs. clip_unset(NULL). This also simplifies the code
a bit. Ideally we should be able to reintroduce clip_unset in EO
if we can have a "@final" tag (like java's final keyword), to
prevent overrides.
Widgets should simply override efl_gfx_color_set and call
super all the way up to evas object.
Legacy compatibility with call interceptors and early call
abortion (eg. delete_me or obj->layer == NULL) are implemented
with an internal call. See the previous commit introducing the
API.
This is a poor man's solution to get rid of group functions such
as clip_set, clip_unset, color_set, etc... See the following
commits.
This API needs to be EAPI for elementary but shouldn't be used
outside EFL. This is required purely for legacy compatibility.
Here's the call flow, inside show(obj):
1. if (intercept_show(obj)) return;
2. show(super(obj));
3. do other stuff
Most of the smart functions "Efl.Canvas.Group.group_xxx" should
not exist and be overrides of the base object function instead.
Cleaning this up is necessary if we want an EO API for custom
smart objects. This patch is the first attempt at removing a
method (the simplest one).
As for no_render, I wonder if propagating to the children
really is necessary. evas_render should skip them already.
Summary:
If the pixels of image object has updates
via native_suface_set api with TBM surface,
does not update on screen(no rendering)
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4340
EO is now extremely restrictive wrt. threads so that efl_data_scope_get()
can't work outside the main loop. This patch fixes the usage to create
sw buffers as shared objects (accessible from both the main loop and evas
async thread) and use plain old pointers where possible.
The buffers now have no parent because efl_add(CLASS, obj_from_mainloop)
does not work with shared objects. This is bad, as the buffers conceptually
belong to the main loop, and only need to be accessible from the draw thread
for a few calls. The main loop determines their lifecycle.
Fixes T4628
And indirectly also Efl.Canvas.Object.
I believe those two classes should even inherit from Efl.Loop.User.
Right now this patch relies on the new dependence of Evas over Ecore,
and is maybe a bit ugly as is.
Ping @cedric
See T4686
Jean-Philippe Andre
Bruno Dilly
Guilherme Iscaro
Carsten Haitzler
Tom Hacohen
Stefan Schmidt
Subhransu Mohanty
Chris Michael
Marcel Hollerbach
Felipe Magno de Almeida
jiin.moon
Daniel Hirt