After splitting font family and size set operation, expedite lost a 10%
speed due to doing a double initialization (Once when the family is set
and one when the size is set). This was noticable in a few tight running
tests. This patch enforce that no initialization is called until the size
and the family are set.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10976
Summary: This is for backward compatibility for TIZEN Test cases for legacy
Reviewers: woohyun
Reviewed By: woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9519
Currently:
User cannot change font size only, he needs to set both font and font size with (**efl_text_font_font_set**)
To change size only, you need to make two calls, one to get font (**efl_text_font_font_get**) , then pass it again with new size to (**efl_text_font_font_set**).
New Behaviour:
If user want to change size only, then he passes NULL as font argument to keep same font.
If user want to change font only, then he passes 0 as font-size argument, to keep same font-size.
Notes:
This is not best solution, but it better than current behaviour.
I think best solution to have separate function to set font size, but It might break current api or duplicate functions.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9158
Summary:
This file is full of functions called as:
foo(eo_obj, obj);
Most of them can be reduced to foo(obj); and internally get the eo_obj
with obj->object
This would make it impossible to screw up calling them passing an
unrelated pair, and make calling code a little more readable.
ref T7230
Depends on D9045
Reviewers: raster, cedric, zmike
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7230
Differential Revision: https://phab.enlightenment.org/D9046
Summary:
This file is full of functions called as:
foo(eo_obj, obj);
Most of them can be reduced to foo(obj); and internally get the eo_obj
with obj->object
This would make it impossible to screw up calling them passing an
unrelated pair, and make calling code a little more readable.
ref T7230
Reviewers: raster, cedric, zmike
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7230
Differential Revision: https://phab.enlightenment.org/D9045
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D8107
Summary:
last function pointer indicates render_pre(),
add one more element is unnecessary.
Reviewers: #committers, netstar
Reviewed By: #committers, netstar
Subscribers: netstar, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6967
Summary:
edje_edit_object_add
edje_object_add
emotion_object_add
evas_object_xxx_add
These APIs had allowed to set parent to EFL_CANVAS_OBJECT(Evas_Object) before
8bb11a17. we should call evas_find before safety check for backward compatibility.
Test Plan:
win = elm_win_add(NULL, "main", ELM_WIN_BASIC);
1. `rect = evas_object_rectangle_add(evas_object_evas_get(win));`
2. `rect = evas_object_rectangle_add(win);`
Check that 1. and 2. works.
Reviewers: Hermet, zmike
Reviewed By: Hermet
Subscribers: cedric, #reviewers, CHAN, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6909
Summary:
A object that is not evas class shouldn't use evas_find. it may occurs segfault.
ref c2e8b492b1
Test Plan:
Evas *evas = evas_new();
evas_free(evas);
evas_object_line_add(evas);
Check weather there is segfault.
Reviewers: Hermet, raster, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6816
A null font set can potentially be stored and passed on. There is no
specific fallback in our codebase to roll-back if something like that
occurs.
This fixes a case where an entry of a null font was not removed from the
fonts_cache and was leaked to subsequent tests (the null font entry was
not removed from the fonts_cache).
Note that this was only apparent when EFL was built with
`--disable-fontconfig`, likely due to fontconfig succeeding to always
retrieve some non-null font.
@fix
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
This removes the internal function pointer for scale_update. This makes
all relevant classes implement the scale API in EO.
This removes the duplicate function in Efl.Canvas.Object and only uses
the one from Efl.Ui.Base interface.
This *seems* to be working as expected. Fingers crossed!
PS: I don't like the name Efl.Ui.Base. It's an interface for a few
common API's between Gfx, Canvas and UI levels... Maybe scale simply
doesn't belong there.
Summary:
dev branch : devs/subhransu/font
The Final goal is to move the evas_font module to ector so that both ector and evas can reuse the code.
make the api simple so that sam eapi can be used by evas_textblock and ector text.
This is the 1st stage to achive that gola, first remove the evas internal dependancy as much as possible before moving to ector library.
Reviewers: jpeg, raster, herdsman, cedric, id213sin
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5419
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
Summary:
If the last item before ellipsis item has bigger width than its advance,
evas_common_font_query_last_up_to_pos() function can find wrong ellipsis position.
When Evas finds a position for non last item, Evas must care about additionally
available space for glyph's width of the given x position.
ex) the last item's glyph before ellipsis item has a tail to draw above the ellipsis item.
@fix
Test Plan:
Test case will added as comment.
(Becasue of font license problem.)
Reviewers: herdsman, raster, jpeg, woohyun
Subscribers: cedric, Blackmole
Differential Revision: https://phab.enlightenment.org/D4727
Summary:
The function already has a precondition test for !font, so this
additional test will never trigger.
@fix CID1371525
Reviewers: cedric, jpeg
Subscribers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4682
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Some property set calls to Evas Text are NOPs if the property was
already set to the same value. Avoid doing any work then.
This adds a missing intercept call (size_set as it's overriden
by Evas.Text).
several calls, specifically evas_object_change_reset,
evas_object_cur_prev, and evas_object_clip_changes_clean that are
called directly or indirectly as part of evas render on at least every
active object if not more, were doing full eo obj lookups when their
calling functions already all had the eo protected data looked up.
tha's silly and just adds overhead we don't need. my test dropped
_eo_obj_pointer_get overhead in perf profiles from 4.48% to 2.65%. see:
4.48% libeo.so.1.18.99 [.] _eo_obj_pointer_get
4.23% libevas.so.1.18.99 [.] evas_render_updates_internal
2.61% libevas.so.1.18.99 [.] evas_render_updates_internal_loop
1.68% libeo.so.1.18.99 [.] efl_data_scope_get
1.57% libc-2.24.so [.] _int_malloc
1.42% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.09% libevas.so.1.18.99 [.] evas_object_clip_recalc.part.37
1.08% libpthread-2.24.so [.] pthread_getspecific
1.05% libevas.so.1.18.99 [.] efl_canvas_object_class_get
1.01% libevas.so.1.18.99 [.] evas_object_cur_prev
0.99% libeo.so.1.18.99 [.] _efl_object_event_callback_legacy_call
0.87% libevas.so.1.18.99 [.] _evas_render_phase1_object_ctx_render_cache_append
0.82% libpthread-2.24.so [.] pthread_mutex_lock
0.81% libevas.so.1.18.99 [.] _evas_render_phase1_object_process
0.79% libc-2.24.so [.] _int_free
vs now the improved:
4.82% libevas.so.1.18.99 [.] evas_render_updates_internal
3.44% libevas.so.1.18.99 [.] evas_render_updates_internal_loop
2.65% libeo.so.1.18.99 [.] _eo_obj_pointer_get
2.22% libc-2.24.so [.] _int_malloc
1.46% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.04% libeo.so.1.18.99 [.] _efl_object_event_callback_legacy_call
1.03% libevas.so.1.18.99 [.] _evas_render_phase1_object_ctx_render_cache_append
0.97% libeina.so.1.18.99 [.] eina_chained_mempool_malloc
0.93% libevas.so.1.18.99 [.] evas_object_clip_recalc.part.37
0.92% libpthread-2.24.so [.] pthread_mutex_lock
0.91% libevas.so.1.18.99 [.] _evas_render_phase1_object_process
0.84% libc-2.24.so [.] _int_free
0.84% libevas.so.1.18.99 [.] evas_object_cur_prev
0.83% libeina.so.1.18.99 [.] eina_chained_mempool_free
0.80% libeo.so.1.18.99 [.] efl_data_scope_get
of course other things "increase their percentage" as oe overhead now
dropped, and things seem to move around a bit, but it does make sense
to do this with no downsides i can see as we already are accessing the
protected data ptr in the parent func.
Textblock filters support RGBA input which means legacy styles
can be used in conjunction with filtering. Not recommended, but
it works. Note: We may decide to drop this behaviour and use
alpha-only inputs for simplicity.
Still missing: support for filtering strikethrough, underline, or
embedded items
This is a preparation step for (experimental) textblock support.
Textblock objects won't have a single filter, and the buffer's
geometry wouldn't be that of of the object itself. Thus a few
internal APIs need to be reworked first.
i found evas_common_draw_context_apply_cutouts() was procsessing 300+
cutouts and as it's O(n^2)/2 to try and merge adjacent rects for
cutouts this really performs like complete junk. we apply cutout rects
a LOT. this is not the best solution, but it's quick and much faster
than doing the clipouts which drop framerate to like 1-2fps or so in the
nasty case i say (tyls -m of photos in a dir with a 2160 high
terminal).
this figures out the target area to limit the count of rects
significantly so O(n^2) is far far better when n is now < 10 most of
the time. and for the few operations where it's a high value this now
uses qsort to speed up merges etc. etc.
@optimize
This patch introduces the possibility to set the pointer mode and
query other properties like current position per pointer device.
The old API will still works, however it will only act on the default seat.
preparing an object is a good idea. especially with gl. you want to do
texture uploads BEFORE using textures all in one batch. otherwise this
may mean the gl implementation has to make a copy of your data in a
tmp location then copy it in later when texture becomes "unused" as it
may be in use at the moment, or it may have to stall and wait.
i have seen somewhere around 7-10% speedups on nvidia and intel
drivers with this on given a very special test case i brewed up (1000
32x32 images where i change 1 pixel every frame). this should have
impact really when we are modifying textures a lot. this is all i've
implemented for now, but this should/would/could do much more like
re-order map, proxy renders to render FIRST in a pre-render list
instead of inline and to pre-render fbo/buffer content for complex
objects like text or textblock etc.
so i have been doing some profiling on my rpi3 ... and it seems
memcmp() is like the number one top used function - especially running
e in wayland compositor mode. it uses accoring to perf top about 9-15%
of samples (samples are not adding up to 100%). no - i cant seem to
get a call graph because all that happens is the whole kernel locks up
solid if i try, so i can only get the leaf node call stats. what
function was currently active at the sample time. memcmp is the
biggest by far. 2-3 times anything else.
13.47% libarmmem.so [.] memcmp
6.43% libevas.so.1.18.99 [.] _evas_render_phase1_object_pro
4.74% libevas.so.1.18.99 [.] evas_render_updates_internal.c
2.84% libeo.so.1.18.99 [.] _eo_obj_pointer_get
2.49% libevas.so.1.18.99 [.] evas_render_updates_internal_l
2.03% libpthread-2.24.so [.] pthread_getspecific
1.61% libeo.so.1.18.99 [.] efl_data_scope_get
1.60% libevas.so.1.18.99 [.] _evas_event_object_list_raw_in
1.54% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.32% libgcc_s.so.1 [.] __udivsi3
1.21% libevas.so.1.18.99 [.] evas_object_is_active
1.14% libc-2.24.so [.] malloc
0.96% libevas.so.1.18.99 [.] evas_render_mapped
0.85% libeo.so.1.18.99 [.] efl_isa
yeah. it's perf. it's sampling so not 100% accurate, but close to
"good enough" for the bigger stuff. so interestingly memcmp() is
actually in a special library/module (libarmmem.so) and is a REAL
function call. so doing memcmp's for small bits of memory ESPECIALLY
when we know their size in advance is not great. i am not sure our own
use of memcmp() is the actual culprit because even with this patch
memcmp still is right up there. we use it for stringshare which is
harder to remove as stringshare has variable sized memory blobs to
compare.
but the point remains - memcmp() is an ACTUAL function call. even on
x86 (i checked the assembly). and replacing it with a static inline
custom comparer is better. in fact i did that and benchmarked it as a
sample case for eina_tiler which has 4 ints (16 bytes) to compare
every time. i also compiled to assembly on x86 to inspect and make sure
things made sense.
the text color compare was just comparing 4 bytes as a color (an int
worth) which was silly to use memcmp on as it could just cast to an
int and do a == b. the map was a little more evil as it was 2 ptrs
plus 2 bitfields, but the way bitfields work means i can assume the
last byte is both bitfields combined. i can be a little more evil for
the rect tests as 4 ints compared is the same as comparing 2 long
longs (64bit types). yes. don't get pedantic. all platforms efl works
on work this way and this is a base assumption in efl and it's true
everywhere worth talking about.
yes - i tried __int128 too. it was not faster on x86 anyway and can't
compile on armv7. in my speed tests on x86-64, comparing 2 rects by
casting to a struct of 2 long long's and comparing just those is 70%
faster than comapring 4 ints. and the 2 long longs is 360% faster than
a memcmp. on arm (my rpi3) the long long is 12% faster than the 4 ints,
and it is 226% faster than a memcmp().
it'd be best if we didnt even have to compare at all, but with these
algorithms we do, so doing it faster is better.
we probably should nuke all the memcmp's we have that are not of large
bits of memory or variable sized bits of memory.
i set breakpoints for memcmp and found at least a chunk in efl. but
also it seems the vc4 driver was also doing it too. i have no idea how
much memory it was doing this to and it may ultimately be the biggest
culprit here, BUT we may as well reduce our overhead since i've found
this anyway. less "false positives" when hunting problems.
why am i doing this? i'm setting framerate hiccups. eg like we drop 3,
5 or 10 frames, then drop another bunch, then go back to smooth, then
this hiccup again. finding out WHAT is causing that hiccup is hard. i
can only SEE the hiccups on my rpi3 - not on x86. i am not so sure
it's cpufreq bouncing about as i've locked cpu to 600mhz and it still
happens. it's something else. maybe something we are polling? maybe
it's something in our drm/kms backend? maybe its in the vc4 drivers or
kernel parts? i have no idea. trying to hunt this is hard, but this is
important as this is something that possibly is affecting everyone but
other hw is fast enough to hide it...
in the meantime find and optimize what i find along the way.
@optimize
Summary:
Visual position of ellipsis item should be set according to
its bidi direction. But, by setting visual position in same way
as logical position, the end ellipsis could be put opposite side.
Also, start ellipsis must placed on left side of RTL text.
@fix T3187
Test Plan: Test an sample on T3187
Reviewers: tasn, woohyun, herdsman
Subscribers: raster, Blackmole, z-wony, cedric, jpeg, minudf
Maniphest Tasks: T3187
Differential Revision: https://phab.enlightenment.org/D3769
Summary:
We can't assume the given font is same with current fdesc by comparing string.
Since Evas starts to supporting "auto" for language,
the given font string should be parsed once before comparing it.
@fix
Test Plan: N/A
Reviewers: tasn, raster, cedric, herdsman
Subscribers: jpeg, minudf, z-wony, Blackmole, woohyun
Differential Revision: https://phab.enlightenment.org/D4227
Summary:
BiDi text is truncated because the way we find the last visual item in text object is wrong.
This patch is similar with _line_native_last_visual_get function in textblock.
Reviewers: cedric, tasn, herdsman
Subscribers: id213sin, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3947
Those are marked as EINA_DEPRECATED since they are for legacy only,
and EDC is the preferred method.
Note: these are new in EFL 1.18.
I would rather have not added them as legacy APIs. This patch is
here to align to Tizen which added them by mistake. Also, remove
the "name" argument from filter_program_set as it's not required,
and also not there in Tizen's code base.
Sorry for the mess.
Cedric BAIL
Ali Alzyod
Carsten Haitzler
Christopher Michael
Mike Blumenkrantz
Hermet Park
Yeongjong Lee
Yeongjong Lee
Daniel Hirt
Cedric Bail
Xavi Artigas
Daniel Kolesa
Mike Blumenkrantz
Amitesh Singh
Jean-Philippe Andre
subhransu mohanty
Youngbok Shin
Bryce Harrington
Guilherme Iscaro
Tom Hacohen
Minwoo, Lee