Check whether we called `efl_part_get` before.
This was happening to C# bindings (maybe a bug there?) but in any case a
failure is safer than a segfault.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9563
Just to check if the edje style has text_class tag we do
lot of pointer hopping by linearly scan through the tags in the
style which is not very cache efficient.
by keeping a readonly flag we can avoid those acess if the style dosen't
have any text_class tags. and if we have those tags then we can start
updating the style straight away.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9546
these function the same as the min size hint versions and enable
distinction between internally-set max size hints and user-set max size
hints
@feature
ref T8122
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9553
seems name for the model property_name is now allowed,
so fix it to title and now it works well.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9558
this is more or less just the max size hint, so just set the max size
hint
ref T7902
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9550
this was more or less just a wrapper around efl_gfx_entity_size_set
and resulted in unpredictable behavior depending on when it was called
instead, simply set the min size hint on the popup object
ref T7902
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9549
Summary:
canvas objects do not need localization because they are not directly user-facing
this should only be inherited by objects which need to be localized
Depends on D9559
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9560
Summary: these are not distributed apis so they should always remain beta
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9559
Summary:
When a map property is changed, map draws it.
Before drawing, evas_object_map_update updates map->spans which is data for
actual drawing. But if changed_map is false, then evas_object_map_update does
not update map->spans.
Usually mapped object has following step.
(1) change map data (evas_map_point_coord_set)
(2) render_pre
(3) evas_object_map_update updates map->spans if changed_map is true.
(4) render
(5) render_post -> evas_object_cur_prev -> "map->prev = map->cur"
But if mapped object hides at step(1), then step(3),(4) does not happen. But
step(4) map->prev keeps changed map data. After this point, If same map data
comes, then map does not draw it. Because the new data is same with map->prev.
The issue occurs with following step.
(A) point_coord_set with point A.
(B) (2)(3)(4)(5) works.
(C) point_coord_set with point B. And hide.
(D) (2)(5) wokrs.
(E) point_coord_set with point A. still hide, so none of (2)(3)(4)(5) work.
(F) point_coord_set with point B. And show.
(G) (2)(3)(4)(5) works. BUT step(3) does not update map->spans because
changed_map is false. So you can see image of point A.
The changed_map is changed to false after updating map->spans at step(3).
So usually changed_map is false before deciding changed_map of next render.
In case of not rendering (but render_pre/post) after map data is changed, the
changed_map keeps true. So this patch was suppose to make changed_map
false if changed_map is already ture before _evas_map_calc_map_geometry
decides changed_map which occurs step(1). true changed_map indicates that
you need to draw even though new map data is same with previous map data.
Test Plan: {F3739770}
Reviewers: Hermet, jsuya
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9476
Summary:
Both font and font_size are already added into the style text
in _edje_format_reparse() function and there we update the tag->font_size
as well as tag->font member. so I think it is unnecessary to
add again which has memory as well as parsing performance impact.
Note :
someone please update this cryptic comment
/* Add font name last to save evas from multiple loads */
how this is going to help saving multiple load.
Reviewers: ali.alzyod, Hermet, raster, cedric
Reviewed By: Hermet
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9543
Reviewed-by: Felipe Magno de Almeida <felipe@expertisesolutions.com.br>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9529
the main user of textblock_style_set() api is the edje whcih keeps its owen edje_textblock_style
tags( string_shared string) by changing the textblock to keep the string_shared string will improve
the chance of sharing the same string hence reducing memory.
By removing the Eina_StrBuf usage inside the loop in textblock_style_set() api we can avoid lot
of temporary memory allocation and deallocation hence will improve performance.
Note: I see lot of places we use Eina_Strbuf inside a loop (eina_strbuf_new() does 2 allocation)
We need to be extra carefull while reviewing when the code uses those construct to see if its really necessary.
Data: it reduces memory allocation by 7000 in elementary_test launch time.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9545
Evas_TextBlock_Style has no idea about the text_class tag its a garbage value to it.
So keep the text_class tag in the edje level and update the text style property in the
final style string when necessary.
Because text_class id tends to be unique by removing from the final style string
enable it to be shared (string shared string).
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9544
asan is most unhappy about using a priori stack frame's data for
this.. it seems check uses the char * buf directly as-is without
duplicating it... so we can't sensibvly use local stack data. that is
what asan is saying... and this makes our tests not work under asan to
begin with... nto to mention other possible issues i have yet to see
as i got to this one first.
coverity doesnt like inconsistent behavior of code, so make it
consistent even if pointless as this is during init when we wont have
threads .... yet.
CID 1403903
in the case pipes fail to create we'll close the wrong ones... this
fixes that. it also happens because i didn't use names consistently.
now it does so it's easier to keep right.
thanks coverity.
fix CID 1396994
on read/decode we can avoid lots of little locks and unlocked by
having the rwlock go to the outside and a single lock+unlock (read) on
the dictionary. it blocks for longer by has less atomics/fence points
as a result and thus decodes faster where changes that we are writing
while decoding is insanely low so no point worrying here.
this is mostly to verify that the internal label is sizing as expected
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9523