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.
Even though ownership info belongs to params/returns/etc at syntax
level, we can still store it in the type and turn several API funcs
into one this way.
This is the new ownership system for Eolian, working on params,
returns, struct fields or events directly rather than specifying
ownership at type level. As the new system will evolve it will
gain missing features and necessary checks.
for both ecore_exe_win32.c and ecore_exe_posix.c when the rare case
(basically almost never) that malloc fails for the exe read/err
buffers also set the data size to 0 so it doesn't lie with a NULL ptr
for data.
@fix
this has affected edje for... like... ever. min size of boxes just
doesnt work. because evas box just doesnt do it right. this has led to
nasty things where edje box is just not usable if you use weight of 0.
btw weight 0 means "stay at min size no matter what even if we expand
the box to be bigger" in edje... which is totally broken and i can't
fix that without potentially breaking even more stuff... but let's
see. i've been using this for several days now and ... i can't find
breakage... so this should fix up SOME issues in edje.
@fix
For example, aliases to ownable types are now also ownable,
which wasn't possible in the previous version, where you could
only own actual expanded ownable types.
Jean-Philippe Andre
Amitesh Singh
Cedric Bail
Carsten Haitzler
Jean Guyomarc'h
Daniel Kolesa
SangHyeon Jade Lee
Felipe Magno de Almeida
InHong Han