Function declared in a .eo are something that we want to allow people to inherit from
or use in a binding. I can't think of a situation where that would be the case for
this function and it solves at the same time problem of needing a shared interface
for both loop and loop_user.
Summary:
Fill in the intro section and the first test mode. (Docs for second
mode will be forthcoming.)
Also drop some of the generic comments that are already explained better
in some of the basic examples.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5201
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The "default" name doesn't mean a lot to edje. Use the helper function
to get the proper seat name.
This fixes IMF for the Entry widget, that did not get triggered on the
hotkey combination.
@fix
The seats list got emptied, but the counter progression was kept,
causing needless different seat names for the same device across
different edje objects.
the error case is when a element is shown, but its parent was not.
In that case intersect returns immidiatly, without evalulating the focus
state again.
calc_size_min was just a helper passing 0,0 to the restricted form.
Let's not duplicate APIs in EO and use an optional argument instead.
Bindings should be nicer and C could use a macro if it's too cumbersome
to pass in 0,0.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
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
Reported by @jiin.moon:
In case of async_open for an elm_image, we try and open a file in a
thread, then map it and populate a bit, as this may take some time
(blocking I/O). This creates a mmap with eina_file_map_new. But later
evas image loaders will (usually) try and map the entire file with
eina_file_map_all() which creates another mmap. Since the size is
different (32Kb first then all) the returned map might be different
(it's up to the kernel to decide at this point).
So, in order to avoid having multiple maps on the same file, and try to
reduce the peak memory usage, we should prefer using the same map all
the time, i.e. the global one returned by eina_file_map_all().
This patch relies on the previous patch in eina_file which fixes
eina_file_map_populate() for the global map.
@fix
This makes sure that the call to madvise is safe. On Linux it's not too
much of an issue as checks are made inside madvise, and the worst that
can happen is an error is returned (EINVAL). Not great.
But if MAP_POPULATE is not present, as is the case on *BSD, then the
internal function _eina_file_map_populate() is used for the populate
rule. In that case actual data is read and we should make sure not to
trigger a segfault or bus error.
Also, this makes sure that in case of HugeTLB we actually populate all
pages, rather than one page out of 8 (we were jumping by 16Mb instead of
2Mb).
Note: Can we get the size of a HugeTLB at runtime? We're assuming 2Mb
which might very well not be the case!
See: https://wiki.debian.org/Hugepages
Tested by disabling MAP_POPULATE and observing crashes :)
@fix
This has been a long standing plan for improving performance in rendering
vector object. If your test involve updating gradient, you will get another
speedup of around 15%. Combined with previous shape, we get a 65% improvement
with doing the CPU intensive computation in there own thread before the
rendering kickoff. This was motly theorical until now, but well, it works
great !
This has been a long standing plan for improving performance in rendering
vector object. Depending on the test, you will get an improvement between
10 to 35% when rendering vector based object.
We are still maintaining the Cairo backend as the default one at the moment
due to a lack of result comparison tests between the two engine. Hopefully
we should get that covered and we can all enjoy a backend that is 4 times
faster by default.
Lukasz Stanislawski
Jean-Philippe Andre
Felipe Magno de Almeida
Daniel Zaoui
Cedric BAIL
Andre Lupa
Bryce Harrington
Daniel Hirt
Marcel Hollerbach
Amitesh Singh