If query at x coord, which points to rigth half of LTR char,
next position will be returned. The same for left half of RTL char.
Signed-off-by: Yakov Goldberg <yakov.g@samsung.com>
Address sanitizer found this. Not really a serious error as text[i] will
be 0 in that case (I believe) and the loop is aborted in any case.
Still, better safe than sorry.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
Since the objects are moved by the framespace offset, it must be
considered when populating map points. This is done when the map is
applied to an object (the map points are updated with the framespace
offset of the canvas that is parent of that object.
Additionally, a flag is set on the map struct to indicate that it had
its points updated already to avoid re-adding the offset.
Applications using these functions should not know of any offset. This
patch makes the canvas pointer position to be returned exactly the same
as on X11 backends.
This check makes no sense, since objects can be on outside of the
screen, with negative position, but they still need to be adjusted by
the framespace offset.
Framespace offset adjustment should be applied to every object not
marked with "is_frame".
Additionally, it should be applied only once. Since it is already being
applied on the *_feed_mouse_* functions, there's no need to apply it
again on the _evas_event_source_mouse_* functions, which are called by
the former ones.
Also add the missing adjustment to the feed_mouse_move one.
- mark all children of a given smart object as "is_frame" if the smart
object is also marked as a frame;
- when moving a smart object, use the originally requested move
coordinate to calculate the offset that the children should be moved
too;
- _smart_move_children_relative will fetch the child position with
geometry_get(), this way getting the corrected object position, before
adding the offset.
1. Added evas_obj_image_preload_begin/cancel APIs.
2. Removed evas_obj_image_preload. This accepts 'cancel' as a parameter and it's so confusing to developers.
3. No ChangeLog/NEWS for this change because Eo APIs were not released yet.
4. Discussed with Raster.
5. It's encouraged to use elm_image however. elm_image has elm_image_preload_disabled_set() API.
Apparently obj->layer and obj->layer->evas can sometimes be NULL. It is
checked in other objects, for example, image object. Add the checks here
to "fix" a crash reported by Christopher Michael.
* Use an Eina_Hash for the garbage collector list.
* Turn off garbage collection on object that are unlikely to match.
This patch make 1.8 as fast as 1.7 again.
Introduce a new function called evas_object_content_change(). It should
be used when object contents get changed.
The rendering issue involving text objects was due to its map surfaces
not being freed. Thus, evas_object_content_change() is now called in
evas_object_text_text_set() during the relayout of the text for making
sure to get their map surfaces freed before rendering them.
Signed-off-by: Paulo Cavalcanti <paulo.cavalcanti@linux.intel.com>
When harfbuzz is enabled, RTL text (arabic, hebrew...) is displayed differently
if the paragraph begins with or without LTR.
The problem was related to the function evas_common_language_script_type_get
and a wrong offset given as parameter to this function.
Thanks to EunYoung Kim for having found this bug.
Signed-off-by: Daniel Zaoui <daniel.zaoui@samsung.com>
Evas_Object_Polygon are a little bit special and track their position
to avoid rebuilding various property when just moved. The offset.{x,y}
are there for that. For a strange reason they got a += instead of just
an = and there our offset did go quickly out of screen...
The _pixel_alpha_get() function used in evas_object_image_is_inside won't
work with engines other than software - since it relies on engine data
being *always* RGBA_Image * - which is wrong for OpenGL backend that uses
Evas_GL_Image * for "engine_data" pointer.
memfile are not used that often like other direct pixels manipulation code.
Merging them into the same structure make sense and reduce the memory cost
for normal image object. Save between 8 to 16 bytes per image object.
SVN revision: 83843
The issue happens when selecting in strings that have both bidi and different
scripts in the same bidi run. E.g: "עבריתenglishрусскийעברית".
SVN revision: 83786
A few days ago I was investigating a bug in the EFL WebKit port and
noticed WebKit's and Evas' handling of Fontconfig are somewhat
incompatible: while the evas_font code calls both FcInit() and FcFini()
when on initialization and shutdown, respectively, WebKit keeps some
Fontconfig objects alive until the process exits. In practice, this
means that shutting Evas down will cause FcFini() to assert because
there are objects which have not been properly destroyed.
This is not really a WebKit-specific problem, as any program which also
uses Fontconfig directly and shuts Evas down before destroying all FC
resources it has allocated is going to crash in the same way.
Other libraries such as Qt, Pango and Cairo do not explicitly initialize
and shut Fontconfig down. Evas itself got this code in r40242 and was
later adjusted in r45829 and r74870.
Since we can't completely control the lifetime of all Fontconfig objects
used in client code, I was thinking of doing the same thing as other
libraries do and get rid of the calls to FcInit() and FcFini(). The part
which is really important is not calling FcFini() -- this was already
done for a while in the r45829 which I mentioned. Valgrind will complain
about some "still reachable" memory blocks, but that's not really
important (as raster said in that revision's commit message, "things may
look like they leak in Valgrind - they dont. in reality").
Note: tasn tried to talk about it with fc guys and it's the
way to go. They won't implemented refcount as suggested in our ml.
Patch by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
SVN revision: 83605
There's an obvious typo in the function name, so appease my OCD and
rename it.
Patch by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
SVN revision: 83604
From now, classes implementing the Eo function with id
EO_BASE_SUB_ID_DBG_INFO_GET will be able to show in Clouseau their own
specific information.
Information contents is controlled by the class itself and no more
by Clouseau. Basic types and lists are supported..
Signed-off-by: Aharon Hillel <a.hillel@samsung.com>
SVN revision: 83410
NOTE: Overall speedup of 7%. No benchmark on memory consumption yet
as they are still running ask me directly to get the number later
today.
SVN revision: 83052
This single test accounted for 1% of my terminology benchmark.
I am considering moving evas_string_char_next_get and
eina_unicode_utf8_get_next to become inline as their function
entry/exit point account for 3% of the same benchmark.
The biggest win would be to get rid of the memcpy _termpty_text_copy
that account for 16%.
In the micro optimization part, we also still do to much malloc
in font_draw_prepare as we don't recycle the array there and account
for 3% of the benchmark in malloc/free there. In the same ballpark
_text_save_top account for 2% of the time in malloc/free.
In that same benchmark, evas_object_textgrid_render account for 5%
where 4% of its time is spend in evas_common_font_draw_prepare. At this
point I am not sure that rewriting textgrid is gona help us at all. We
will win almost as much by just inlining the get_next things in evas
and eina for a minute of development time.
SVN revision: 82927
Expedite biggest test memory win 100KB, average 10KB.
No slow down in proxy test (+/-3%). Speed up in most other
case (average speed up is +5%), likely due to much more
cache hit.
Elementary test show a win between 100KB to 600KB depending
on the test you are considering.
Now, you can see how I intend to use Eina_Cow and the expected
win we can have from it. I don't intend to do more for the
rest of the week so you have time to comment.
SVN revision: 82924
This new engine function will only be used in software generic for
now - since it's the only engine used with the async render.
This function has been introduced in order to avoid growing thread
command queue too much to draw a text_props at a time on render calls
from textgrid objects.
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82832
Unfortunately, although the pre-cast code is correct, we need the cast
because of the way gcc handles the types (magic) when passing va_args on
64 bit. This doesn't change anything logically.
SVN revision: 82827
This patch should make us get a reference on images, maps and glyphs
which are sent in a command to the render thread. Before we were doing
some useless ref and unref operations.
SVN revision: 82666
This is intended to preserve old behavior now that we have
evas_common_font_draw_cb() to handle both sync and async callbacks.
However, we need to check where why we end up with no glyphs in a
text_props even after calling evas_common_font_draw_prepare().
SVN revision: 82664
This sould bring back a little bit of text rendering performance, while at
the same time decreasing memory usage and fragmentation.
Patch by: Leandro Pereira <leandro@profusion.mobi>
SVN revision: 82660
count is type 'int', but used as unsigned it (always > 0), however gcc
can't understand that and is complaining that 'check' could be used
without being initialized... which is false. Make the test != 0 to
silent gcc and make code as correct as before.
SVN revision: 82369
Fixed queue cache handling to let enqueue and process happen at the same
time, even though this is not our use case yet. This also solves a race
with the assignment of cache variables outside the queue lock and
remembers to free the cache when shutting down.
SVN revision: 82296
it is "const char * const *", not "const char **", and it was triggering a warning in our code.
it's just constness and will not trigger an error in our user's code, just an warning that he should fix.
SVN revision: 82278
This patch introduces fields to event Evas_Event_Mouse_* structures
to hold the event source evas object in case of evas source events
propagation.
SVN revision: 82138
NOTE: There is still an issue with text rendering, that
is still 4 times slower and impact all text object (text,
textblock and textgrid).
SVN revision: 81912
Also postpone marking the rendering flag until we know we will have
the draw thread do its work. This way we avoid waiting forever at
evas_render_rendering_wait() when the draw thread is also blocked.
Patch by: Ulisses Furquim <ulisses@profusion.mobi>
SVN revision: 81798
This function was basically never working correctly. Everything was
fixed by simulating the evas_object_image_render() workflow, but
instead of actually draw we just check the pixel transparency.
Bugs fixed:
* fails when image is scaled up (could segv) or down (incorrect values);
* fails when image is moved to negative x,y;
* fails when border was being used.
Now everything is fixed and seems to work properly, except I'm not
handling the map and get_pixels() cases, these are marked with ERR()
so we can fix them if someone needs.
SVN revision: 81410
Whenever we copy an image, making it write-able
(evas_object_image_data_get(o, 1)) or just start painting a pristine
buffer (evas_object_image_size_set(o, w, h)), we must mark the image
as loaded to avoid trying to load it (and failing, marking the whole
thing as EVAS_LOAD_ERROR_GENERIC).
SVN revision: 81409
This is in preparation for threaded render landing: the render thread will
hold a reference to a text object's glyphs while it hasn't been rendered
yet (and will drop that reference after drawing). This changes the internal
API a little bit (evas_common_font_rgba_draw() now takes an Evas_Glyph_Array
instead of an Evas_Text_Props).
SVN revision: 81183
* a single option --with-evas-dither-mask=TYPE (big, small, line or none).
* make a wise decision to fallback to small dither mask for
conversions that do not support "no-dither" or "line". Before if
you did not specify it would fallback to big (128x128).
SVN revision: 80383
After agreement in the mail list, core developers agree to remove this
engine that was not being supported for a long time.
Given that most operations Evas uses are not accelerated in DirectFB,
or at least hardware that exclusively supports DirectFB, it's better
for those people to just use Evas/Ecore software (buffer) rendering
and expose DirectFB's framebuffer as destination surface.
SVN revision: 80232
If information like size, scale down, dpi or region is set to any object,
or even if reload of that object is required, evas_object_image_load() is
called and Evas needs to pass scaling information through load_opts as
evas_object_image_file_set() does to Cserve2 as well.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 80176
there are some early-return code that were leaving the size_hint as it
was before, then if you removed every child it should go to 0x0 but
couldn't.
PLEASE BACKPORT THIS TO 1.7 BRANCH FOR ME :-(
SVN revision: 79948
This patch refactors common code for map draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79855
This patch refactors common code for line draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79854
This patch refactors common code for font draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79853
This patch refactors common code for image draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79795
This patch refactors common code for rectangle draws - so that it can be
used by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79785
Hi all,
I had prepare some fix for evas_object_key_grab function.
In my opinion when given modifiers are equal it should return FALSE.
Please verify attached file.
Regards,
Patrick
Signed-Off-By: Patryk Kaczmarek<patryk.k@samsung.com>
SVN revision: 79563
and use the Point structure for clean code.
Signed-Off-By: Leandro Dorileo<dorileo@profusion.mobi>
Signed-Off-By: ChunEon Park<hermet@hermet.pe.kr>
SVN revision: 79224
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Tom Hacohen
Yakov Goldberg
Cedric BAIL
Daniel Willmann
Rafael Antognolli
Daniel Juyung Seo
Carsten Haitzler
ChunEon Park
Cedric Bail
Daniel Juyung Seo
Igor Murzov
Paulo Cavalcanti
Henrique Dante de Almeida
ChunEon Park
Daniel Zaoui
Ivan Briano
Paulo C. A. Cavalcanti Jr
Jaehwan Kim
Raphael Kubo da Costa
Mike McCormack
Christopher Michael
Aharon Hillel
Jiyoun Park
Boris Faure
Gustavo Sverzut Barbieri
Ulisses Furquim
Leandro Pereira
Paulo Alcantara
Stefan Schmidt
Mike McCormack
Leandro Dorileo
Tomas Cech
Jonas M. Gastal
Vincent Torri
Christopher Michael