NB: Master clip is needed so that things don't draw outside the client
area.
NB: This is a partial fix. Still a work in progress. Some remaining
issues with some various elm_tests that use evas_map.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Markup_get was misbehaving and returning wrong results with some escaped
chars. markup_to_utf8 was working correctly. Merged the code together
and now both are consistent and correct.
Thanks to WooHyun for reporting.
Tracking only the async rendering canvases and just waiting for the last one
to finish rendering. This should be enough to sync all canvases since the
render thread orderly executes the commands.
evas_render_sync() will loop through all canvases and wait for their
rendering to finish. Since this function will execute from the main
thread that will sync all of them.
If a text object is rehinted after it is deleted,
baaad things happen. Mark Evas_Object_Text as dead by
setting font to NULL.
Note the crash happened with cserve2 and maybe not in normal
cases.
This issue cause non-letter RTL characters not to be detected as RTL
which in turn turned off bidi for those strings.
Example broken text: <RLM><LRO>[PAS<RLO>[--DES<PDF><PDF>.
Thanks to Yakov Goldberg for reporting this issue.
This check is not necessary but causes incorrect clipping issues.
At this moment, if primitive objects (except image) is the source then that code may be helpful but it doesn't guarantee same behavior for all the primitive objects.
So, right now removed it.
NB: Image_Entry passed in to this function Could be NULL (hence the
previous if ie check above. Do not call evas_cache_image_drop on a
NULL Image_Entry as evas_cache_image_drop does not validity checking.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
NOTE: I am tempted to mark evas_object_memfile_set() as deprecated due
to the forced memcpy it introduced and the fact that it is now a 3 lines
of code to do the same in a more efficient way.
This is not the perfect solution at this moment. This doesn't consider the cached clipper's visibility at all.
But at least this would be better than exist works. Should be improved.
as pointed out by y.usishchev@samsung.com - this code is copy & paste
badness, but the compiler optimizer fixed it up already, so it made no
difference in real life.
Since we locked the font_draw mutex earlier, we should unlock it
before we return.
NB: Fixes Coverity CID1039382
Signed-off-by: Chris Michael <cp.michael@samsung.com>
wanted here...Or (!(ob->map->cur.map->count == 4)) ... but not much
difference either way ;)
NB: Fixes Coverity CID1039673
Signed-off-by: Chris Michael <cp.michael@samsung.com>
would not have gotten to this error handler if it did (so no point in
checking for it and calling functions using it).
NB: Fixes Coverity CID1039926
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In some cases we could return extra formats that are outside of the
range. It's actually not completely fixed yet.
Thanks to clang-analyzer for detecting this.
When opening an image, OPEN and SETOPTS were always sent
consecutively. Merging these two messages may improve the
performance a bit (not measured), but also simplify the
whole thing.
Note: cserve2 debug tools have not been fixed yet.
Evas loaders' open() function expect the key to be a stringshare,
so declare it as such and keep using ref() without add().
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
Most of the time, the SETOPT message is sent only
to carry 0 data. Let's add a flag to the OPEN message to
avoid useless socket calls.
Server-side: implement with message faking.
Also, fix image ID logic on client side:
- alloc data entry asap,
- assign image_id during call to OPEN
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
The LRU should not be limited to 0 byte otherwise all scaled
images will be dropped and reloaded constantly, killing the
performance.
The size is inspired from the scalecache's size of 4Mb.
Variable: EVAS_CSERVE2_SIZE (number in Mb)
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
evas_common_font_int_cache_glyph_get), then we should free that
allocation when we have an error.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Fixes a memory leaks in evas_common_convert_yuv_42* and actually makes
these functions more useful. It's a win-win.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
NOTE: when using Evas_Object image preload infrastructure the GL texture
upload was uploaded from the main loop during the rendering stage. This
could lead to some frame drop during fast animation due to the time needed
to upload that texture.
This patch fix this problem by uploading a small texture quickly (16x16)
and waiting for going back to the main loop to be able to use the same GL
context from another thread to do the texture upload asynchronously without
blocking the main loop.
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
In case of EACCESS, there is no point trying forever
In case of EINTR (interrupt), we can consider for now
that any signal will prevent the use of cserve2.
If we don't do that, Ctrl+C simply won't work :)
Evas_GL Direct rendering is an optimization path that renders
directly to the window if conditions are met. Because evas gl
backend used to re-render the entire screen, evas_gl direct
rendering didin't have to concern with partial region rendering.
Now that partial rendering/swapping has been applied to evas gl-
backend, evas_gl direct rendering also had to take into account
clip regions. in order to properly apply it, some adjustments
were made to the engine functions and etc.
This reverts commit 9473c4a9a5.
This commit is not correct. It just goes through every font in the
fontset, which is usually all the fonts in the system and tries to get
their ascent/descent and by that getting the max ascent/descent. This
won't work nicely.
The solution is to properly fix textblock, if you think there's
something lacking (I.e in the same way I did text).
However, my changes did not change previous behaviour, but were just
wrappers, so I don't see why extra changes would be needed. Please
elaborate.
I'm reverting this because:
1. I don't think it's correct.
2. It severly broke e in some cases (reference:
http://www.enlightenment.org/ss/e-51b5d5e98cd387.04568822.png ).
If this function is called recursively, it will free the list of post
callbacks before the list stops being used, which will cause a segfault.
The only place where this seems to happen is on
https://phab.enlightenment.org/T124, probably due to the extensive mouse
events which are launched in an unexpected way.
This bug started happening after commit
164cc07237395f8fe6efa465e4f0c0c4863f78ed, where the
_elm_scroll_page_x_get() started being called by a post_event callback,
and forcing an edje recalc. This recalc triggered another post_event
callback, thus causing the mentioned segfault.
If there's a better way to prevent this from happening, please change
the mentioned code.
Additional fixes to cc4cf77865.
There were two problems:
1. Usage of max_ascent instead of ascent.
2. Initialization of the ascent value according to the first font,
instead of 0 (as the first font might not even be used).
Account for the framespace offset on perspective fx and fy of each map
point.
This is just a workaround because I could not understand exactly why it
is needed. When no perspective is used, the viewport is set to the size
of the surface, and each map point seems to be used as is, with no
adjustment being needed.
However, when the map is not flat (perspective is used), a more complex
math is used to find the glViewport size. It ends up being bigger, but
there are some offsets used to compensate that, gc->shared->ax/y, which
are added to each vertex before pushing them. Thus, it seems to me that
the framespace offset should not be added to them, but things are weird
if this is not done.
Anyway, I just added those offsets, and it should not impact on gl_x11
since it's not using framespace, and software engines don't seem to
implement perspective anyway, so it all should be fine.
If anyone understands better what's going on here, please make a proper
fix or at least contact me to explain the problem, and maybe I can fix
it by myself.
It seems some images are fully loaded even when we request
only preload. The load handler will take care of both cases anyway.
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
This is an astonishing bug, I wonder since how long it has been there. It
is basically due to the use of void * and a wrong cast. Type checking is
clearly useful, let's use it more !
This causes the textblock layouting problem.
It should be checked when does it really render_pre() called.
If someone knows the reason of this, please ping me.
This reverts commit 3c53b824d8.
This is a bad idea for now, as we need to mark some more events as hot
(including compat generated ones) before doing it.
For native surface rendering (glX, egl) in gl-backend, if pixel get callback
function is called for native rendering, there is a case where evas will
try to call evas_gl_common_context_flush() to flush its remaining commands
in its command queue while the context is set current to the native surface/
context that is called within the pixel get callback. So, I've added an
engine function that forces a flush before it enters the pixel get callback
function.
CEDRIC... it WAS YOU!... YOU BROKE ETHUMB!... i was.. RIGHT! :) well
done. your borking skills are pretty good. :) you broke load opt
downscaling for jpegs in general.. it just happened to turn up in
ethumb.
Before this patch, the proxy will be clipped if the source is clipped by output area even if the soure_clip is disabled,
Additionally, src_clip/src_event/src_visible options must be supported in edje.
Goal is to be able to remove all internal Evas call from inside all
loader module. To do so we are going to open and hold a reference to the
file from outside of the module, read the header, create the image data,
load the data, close that reference.
Once that done, the next step is to let the file remain open as soon as
the filename/key is set and add an API to set an Eina_File directly. This
way edje can maintain the same file open as it use for an edje object,
keeping things in sync and avoid rendering glitch during update.
Ecore_Evas_Input should use this function to report mouse move events.
The previous used function should be used to refeed events, or to
artificially feed mouse move events to the canvas. Basically every other
feed_mouse_move use case that is not an event from the input system.
This function should be used internally by the input system
(Ecore_Evas_Input) to feed Evas with move events. The x,y event info is
relative to the base of the window/surface, instead of the 0,0 of the
canvas.
This case only happens for now under Wayland, where the 0,0 of the
canvas is translated due to the window decorations that are drawn by the
client.
The framespace offset must be taken into account when searching the list
of objects which received events, since the objects now have their
original position.
Instead of moving the objects by adding the framespace offset to them,
use this offset when rendering them. This way there's no change in the
object's geometry/position, it works correctly with map, and will be
automatically updated in case that the framespace values change (for
instance if one sets a window to borderless).
There are 2 main places where changes were needed:
- output redraws, when they come from an object being changed, must be
add the framespace offset to their damaged area;
- checks to see if the object is inside a given rendering area, must
also add this offset, since the object is actually being rendered on
a different position;
Now, Evas.h includes three new files:
- Evas_Eo.h: Eo API functions (functions defines, enums, base id).
- Evas_Legacy.h: contains the API functions related to objects
- Evas_Common.h: common data (structs, enums...) +
functions not related to objects.
This phase is needed for the EFL 1.8 release to disable Eo APIs if we
consider it is not enough mature to be used by applications.
This clipper caused several bugs already, and there are some bugs still
not fixed. Let's remove it and try to fix any remaining with some other
kind of solution that does not depend on adding or clipping objects
during the evas render phase, which causes unexpected behavior.
These objects should be clipped only during rendering, since keeping
them clipped after that allows for unexpected behavior on the
application side. For instance, an application could check if objects
have clippers before doing something to them, assuming that some objects
should have no clipper, but under wayland, after the first render
iteration, there will be no objects without a clipper.
This commit fixes this behavior by unclipping objects that had no
clipper prior to the render iteration.
Additionally, it fixes a bug where a maximized/fullscreen window could
have not all of its content rendered immediately. This was occuring
because some objects could be clipped to the framespace clipper, but
considered invisible in the beginning of the render phase, where they
are evaluated. They were considered invisible because the framespace
clipper object was not resized at that phase yet, and thus these objects
were being clipped out from the viewport.
Eina value type does not support pointer so I used int as of now.
This needs to be converted into hexa later.
By using Clouseau, one can see this Clipper information.
If logical cursor is between LTR/RTL text two cursors will be shown.
Upper cursor is shown for the text of the same direction as
paragraph, lower cursor - for opposite.
NOT DONE YET
Signed-off-by: Tom 'TAsn' Hacohen <tom@stosb.com>
%f causes 0.0000 to always be printed... changed to %d
to get the desired/correct output result.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
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
Chris Michael
Tom Hacohen
Carsten Haitzler
Cedric Bail
Ulisses Furquim
Jean-Philippe Andre
WooHyun Jung
Mike Blumenkrantz
ChunEon Park
Chris Michael
Stefan Schmidt
Yury Usischev
Rajesh P S
Jiyoun Park
Yakov Goldberg
Daniel Juyung Seo
Daniel Willmann
Raphael Kubo da Costa
Christophe Sadoine
Rajeev Ranjan
Sebastian Dransfeld
Sung W. Park
Rafael Antognolli
Jihoon Kim
ChunEon Park
Daniel Zaoui
Daniel Juyung Seo
Cedric Bail
U. Artie Eoff
Rafael Antognolli
Igor Murzov
Paulo Cavalcanti
Henrique Dante de Almeida
Ivan Briano
Paulo C. A. Cavalcanti Jr
Jaehwan Kim
Mike McCormack
Aharon Hillel
Jiyoun Park
Boris Faure
Gustavo Sverzut Barbieri
Ulisses Furquim
Leandro Pereira
Paulo Alcantara
Stefan Schmidt
Mike McCormack
Leandro Dorileo
