stable release - cherry-pick me!
We propose a patch that reduces graph traversal work in
evas_object_child_map_across_mark(). It fixes a few particular
slowdowns around Tizen applications, including 0.6 seconds slowdown.
evas_object_child_map_across_mark() does not seem to need to
recursively call itself on the same object many times. Yet we have
noticed that in some scenarios it repeatedly traverses the same
subtrees of objects over and over again, whenever there is more than
one way of reaching these subtrees. In the production issue mentioned
above, certain elm_object_part_content_set() call results in millions
of recursive calls of evas_object_child_map_across_mark(), taking
~0.6sec total.
We propose to allocate a hash table during top-level call to store all
objects visited, and return from sub-calls instantly whenever we are
called over an object we already visited.
stable release - cherry-pick me!
there way a problem with software rendering - it rendered some areas
more than once per frame due to overlapping rectangles. it also had
more rectangles to cover the same update area that it should have had.
this fixes this.
This is the correct implementation of the idea developped in Lucas De Marchi's blog :
http://www.politreco.com/2013/09/optimizing-hash-table-with-kmod-as-testbed/
This give an interesting +15% for all Eina_Hash user whatever hash function they use. The inlined
djb2 is still the fastest one and all other give very close result. It does increase memory foot
print, but as much as the previous way of doing it.
This is not perfect, it will just limit the propagation of the problem
for some time. Yes, it does hide it under the carpet, but that's better
than having a crash. Problem seems to be in Eina_Hash, but is really
difficult to reproduce and fix for the moment.
This bug is particularly visible in EFM video preview ( T 539 ). The problem is
that the logic for changed has evolved over time. At the beginning Evas canvas
was flat and could be handle in an array. It was then not using the changed flag
that much. This day, we are living with a tree and we need to propagate the
changed flag to the parent, so that when we walk them we only need to walk the
active objects and don't spend our time on branch that are completely static.
Sadly things did collide here. We remove all object that have been rendered
from the pending_objects array. That does include any smart object that was
processed even if one of the child was not. Once any of the child of that not
processed object is marked changed, it will be propagated up to the first
parent that is changed. As the parent of that one are marked as not changed
when evas_render walk the tree, he is blocked really early in the process and
never get a chance to detect that the child of a not changed object did change
and tada !
The fix is to add all the parent of all the object that are in the pending_objects
array back into the pending_objects list. So they will always be marked as changed.
Another alternative to this logic would have been to change pending_change to
filter out those and keep them around. I choose the first solution as I think it
will be more robust to catch all the parent in all case.
This reverts commit 1319733cae.
Let's revert this patch and lower the recursion number.
As we released efl 1.8, let's find the root causes of the problem and fix them.
I already told this revert to raster so I am not mean :)
Summary: Adding an option to use a cubic-bezier curve in edje transitions.
Reviewers: Sachiel, cedric, raster
Reviewed By: raster
CC: raster
Differential Revision: https://phab.enlightenment.org/D319
Summary:
Hello guys,
We are now working on a accessibility support for elementary (ATSPI2) and we need following function to correctly register application.
Reviewers: cedric, raster, lucasdemarchi
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D327
The previous workaround used to send a mouse up event to the
application, using the pointer enter callback to determine when an
implicit grab has finished. This was "simulating" a mouse up event when
the surface move or resize finished.
However, this doesn't work for touch-based move. The pointer enter isn't
emitted, because the wl_touch interface doesn't have the concept of a
pointer.
Changing this code to make it more similar to what Weston's toytoolkit
does, the mouse up event is sent as soon as the move or resize grab
starts. After that, the compositor takes care of the move/resize almost
entirely.
Should fix T468.
down_info is a struct that stores some information about the current
pressed touch events. It should be used for that specific touch point,
instead of the generic input info, when sending a mouse_up event.
This happen because proxy was already freed and we try print some information
about the proxy in error message.
This fix: https://phab.enlightenment.org/T543
Summary:
Block SIGCHLD during select().
This fixes a bug with edje_cc when EVAS_CSERVE2=1: Fixes T464.
select() used to return prematurately with EINTR because the
app received some unexpected signals. In particular SIGCHLD
is received when a child terminates, but this is not a reason
to cancel the image load.
In theory, all blocked signals in pselect() should be pending
until pselect returns, so any SIGCHLD should still trigger
the app's signal handler.
Reviewers: cedric
CC: raster, cedric
Maniphest Tasks: T464
Differential Revision: https://phab.enlightenment.org/D357
I have no idea how the previous formula was supposed to work at all, but
this one is the same as our alignof code to make sure we do allocate to
the really nearest size and don't do over allocation. Additionnaly it works.
eina_array_remove() didnt ever realloc down unless we went to 0
members. this wasn't very good as you'd expect the array to be reduced
in size if enough items were removed. not only that the old code was
stupid and ALWAYS malloc()ed a new array of the exact same size and
copied items over in the most complex way possible, then freed the old
one. this would have added overhead wherever used (evas_render) that
should not have been there.
this is based on the idea in a patch from
Viacheslav Lvov <v.lvov@samsung.com>, but this is a re-do of it
entirely, reducing the codebase massively even compared to the patch
and making it much simpler to read, maintain, actually reduce memory
and cut overhead.
According to clang static analyzer it is possible to find a path where
buf and svr->buf are pointing to the same array, better be safe than sorry.
Arguably this code could be more readable if it was using Eina_Binbuf.
The maximum index of tagname is 7, and preedit_type_size is equal to 8.
Checking "attr->preedit_type <= preedit_type_size" implies that the value of "attr->preedit_type" may be up to 8
This patch fixes CID 1039308