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