This function was moved out of inline (see d7c6fca6c0) but
unfortunately the early checks at its beginning are likely
to result in an early return. Inline this part so we get back a
better performance. Inlining the whole function does not improve
the performance, as GCC simply gives up with inlining.
Note: Between 1.18 and master the number of calls to clip_recalc
has simply blown out. It is thus crucial to find out where those
calls come from but also micro-optimize the function itself. This
patch does the latter only.
@optimize
No need to verify that the clip is an evas object unless we're
actually going to change said clipper. This has a minor effect,
removing ~10% of all calls to efl_isa (0.1% of everything).
After all those efl_isa patches the number of calls has dropped
from 1.9M (~3.05%) to ~570k (0.76%). More can still be done,
surely. Now efl_isa accounts for ~0.05% of my CPU usage according
to perf top (down from ~0.7%).
If edje uses EO APIs instead of legacy image APIs, then many of
the remaining calls will vanish.
@optimization
In relative smart move, we only need to check once that the object
is indeed a valid smart object. This drops the call count from ~1.02M
to ~785k.
@optimization
This avoids calling efl_isa and locking the async mutex.
In callgrind analysis, this reduces the count of calls to
efl_isa from 1.96M to 1.02M.
@optimization
Summary: I had fixed some typos and some wrong expressions, such as capital letters, singular, and orders of groups in Eina API reference doxygen.
Test Plan: Doxygen Revision
Reviewers: stefan, cedric, raster, Jaehyun_Cho, jpeg
Reviewed By: jpeg
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4674
Summary:
Also fix warning about lack of a format string:
warning: format not a string literal and no format arguments [-Wformat-security]
fprintf(stdout, commands);
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewers: cedric, jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4673
If HAVE_GETPWENT isn't defined - the closing brace was missed.
Also prevent situation when strdup() tried to duplicate NULL
pointer, because that could cause segfault.
@fix
Summary:
When you set gravity 1 on scroller, scroller sticks to the bottom
even content is changed.
however, scroller don't work like above, if size of pan is changed.
this commit uses pan_pos_max rather than w/h of content_info
because pan_pos_max is related with both content_size and pan size.
gravity_set will work properly even if both size of content and pan are
changed simultaneously.
Test Plan:
1. Select 'scroll3' in the elementary_test
2. Append enough items so that scroll bar appears (about 30 items)
3. Go to the bottom and Set gravity 1.0
4. Check that scroller sticks to the bottom once you append another item
(it works)
5. Check that scroller sticks to to bottom once you resize window(pan)
(it doesn't work without this patch)
Reviewers: eagleeye, jpeg, cedric, woohyun, z-wony, herdsman
Differential Revision: https://phab.enlightenment.org/D4665
Summary: this should fix some spamming in e
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4675
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
when a few recursive event emissions are happening, and in some deep
recursive level a subscription to the same object is happening, the
subscription would just be executed when the complete recursion is done.
that is wrong. The subscription needs to be executed when the event is
called after the subscription is added, undepended from any recursive
level. That fixes that and adds a regression test for it.
This was discovered in e, since e gives a lot of error messages about a eo object
that is already freed. It turned out this object is returned from evas, and exactly
the above happened to the EFL_EVENT_DEL subscription of that object.
Test Plan: make check
Reviewers: tasn, cedric, stefan_schmidt
Subscribers: stefan_schmidt, netstar, zmike, raster, jpeg
Differential Revision: https://phab.enlightenment.org/D4656
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: I had fixed some typos and some wrong expressions, such as capital letters, singular, and orders of groups in Edje and Eet API reference doxygen.
Test Plan: Doxygen Revision
Reviewers: stefan, cedric, raster, Jaehyun_Cho, jpeg
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4666
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This fixes the following ERR message:
ERR<10589>:eina_safety /home/jpeg/e/core/efl/src/lib/ecore_evas/ecore_evas.c:3149
_ecore_evas_mouse_move_process_internal() safety check failed: cursor == NULL
Also support both Evas.Image and EO Efl.Canvas.Image classes.
Add a test case in elm_test (under "Icon").
I'm not so happy about this patch... it shows that the API
barrier between legacy and EO implemented for images may not
be such a great idea after all :(
The previous patch (b184874fa5) was preventing
post-event callbacks from triggering any form of input event,
including side-effects due to mouse,in. In fact by tracking
which exact events we want to post-process we can support
proper recursion. This fixes crashes in Bryce.
I'm not changing the documentation as this is still a dubious
code design.
Fixes T3144
Fixes T5157
See T3144 that I marked as Wontfix.
Bryce in E manually feeds events from a post-event callback
resulting in Evas going insane and leading to frequent crashes.
The ideal solution (for E) would be to ensure that everything works
smoothly, the input event data is valid up until the post-event cb
is called, etc... Unfortunately, with recursive events the exact
order of operations may be messed up: the post-event
I don't want to add yet more complexity to Evas events here (it's
already spaghetti all over the place) so I'm simply blocking any
new event feed when running the post-event callback list.
It's not possible to just freeze the events (I tried, it failed).
**********************
Some more explanation:
post-event callbacks are used to implement reverse-order logic
where the on-hold flag of an input event may be set by an event
listener that does not come first.
Here's a situation to illustrate: scroller A inside scroller B.
As events are propagated from children to parents (assuming the
propagate flag is set), we'd assume the events to go first to A
and then to B, which means a mouse wheel event would make the
inner-most scroller (A) scroll, and the outer-most scroller (B)
wouldn't budge.
But as things are designed, A and B are not simple evas objects,
and the actual event-catching object is a top-most transparent
rectangle (top-most in Z stack order). Since A is inside B, B's
rectangle BR is over A's rectangle AR, thus catches the wheel
event first. But in terms of UX we still want A to scroll, not B.
The solution then is to reverse the event processing order and
post-event callbacks are the way to do that. This comes with the
consequence that the event_info needs to remain valid until the
post-event is called, and stay the same (so that the on-hold flag
set by A can be read by B).
Recursive events (by explicit feed or modifying the canvas so
that mouse,in or mouse,out are triggered) mess with this logic,
and trigger the post-events too early (event is not fully
processed) or too late (event_info is not valid anymore... and
crash!).
Thanks @raster for explaining the goal of post-event callbacks!
This reverts commit b8beb6834b.
this now actually works... for some mysterious reason... ? :/ i am
baffled. go back in until we can find the issue then...
Summary: I had fixed some typos and some wrong expressions, such as capital letters, singular, and orders of groups in API reference doxygen.
Test Plan: Doxygen revision
Reviewers: stefan, cedric, raster, Jaehyun_Cho, jpeg
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4658
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
On systems where this happens it'll probably happen a lot, so
we don't want to continuously log this, but since it's definitely
showing a bug somewhere (efl or kernel) it probably should be an ERR.