summaryrefslogtreecommitdiff
path: root/src/lib/evas/canvas/evas_map.c (unfollow)
AgeCommit message (Collapse)Author
2016-06-21evas: Rename Evas.Object to Efl.Canvas.ObjectJean-Philippe Andre
One step closer to make the EO inheritance tree look like it's all Efl.
2016-05-06evas: let's reuse what we know when possible to avoid more useless ↵Cedric BAIL
eo_data_scope_get.
2015-07-02Evas: Replace image_map_surface_free by common image_freeJean-Philippe Andre
Those two functions were doing exactly the same thing[1], which is free an image, so this commit only attempts to simplify the code a little bit. [1] Actually image_map_surface_free() might even not have worked properly with cserve2 sw (calling unload instead of close).
2015-05-29eina: beginning of a generic quaternion API.Cedric BAIL
2015-02-12evas - render - have lock point to allow for async obj walk + update addCarsten Haitzler (Rasterman)
this adds a lock for when walking all the objects to generate render commands for an async render. this allows even the object tree walk plus update area caluclation to be moved off into async if every oject that can change canvas state actually does so correctly. this change adds all those lock block calls to synchronise with an async object tree walk.
2015-01-23evas/map: make an internal function to static.ChunEon Park
no need this function set external.
2014-11-28evas/map: remove old comments.ChunEon Park
It's been so long. even SLP is not a valid name anymore. No idea whether the problem still exist or not. If it is then it should be reported and fixed.
2014-11-28evas_map: Remove unnecessary check for current mapJaehyun Cho
Summary: Remove unnecessary check for current map @fix Reviewers: Hermet Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D1708
2014-11-28evas_object_main: Keep map effect after evas object moveJaehyun Cho
Summary: Keep map effect after evas object move @feature Reviewers: raster, cedric, Hermet Subscribers: raster, cedric Differential Revision: https://phab.enlightenment.org/D1678
2014-10-20evas: evas_map - fix cast from double to int with using lround()artem.popov
Summary: All points in map are double, when try to get point coordinates, there are issues with rounding. @fix Reviewers: Hermet, raster, seoz, cedric Reviewed By: cedric Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D1554 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2014-06-22Evas map: Add missing EINA_MAGIC checkJean-Philippe ANDRE
2014-06-03Efl: Update code to use the new class names generated by eolian.Tom Hacohen
2014-03-13evas: let's not access a potential NULL object when looping on a corrupted ↵Cedric BAIL
object list. This fix CID 1191920.
2014-03-12Eolian: Integration of Evas Object.Daniel Zaoui
const have been added in object parameter of two legacy APIs to fit Eolian generated files. Since these functions retrieve information from object, it is logic that the object would be const.
2014-02-05evas/map - added comment to do.ChunEon Park
2014-01-06evas - fixed side effect caused by f4d24e962dba33bef8f990ce3359c06eed8771d0ChunEon Park
since the map_changed is reset right after the map is updated, it could not decide to redraw the map surface properly. now map_update() returns the value to redraw the map surface properly.
2013-12-19evas/map - ensure map updation.ChunEon Park
for more gurantee to update map properly, we should reset the map changed flag after the map updation is performed. this will fix a mapbuf bug that map is not updated. when the map is changed without rendering but it's in the active object list, the map updation couldn't be happened later that map is rendered. (if the map is not updated at this frame)
2013-12-19Revert "evas/map - commeted out insane compare."ChunEon Park
This reverts commit b259cfafe5a758b219f0e80256653358a6a6d62b. my fault. the compare is reasonable.
2013-12-19evas/map - commeted out insane compare.ChunEon Park
cedric, is it just typo?
2013-09-17Fix formattingChris Michael
Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-09-17Remove extra blank spaceChris Michael
Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-06-20efl: formattingSebastian Dransfeld
2013-06-20evas: Keep sane name for public headerSebastian Dransfeld
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.
2013-06-13evas/map: Add FIXME comment to remember that it's just a workaround.Rafael Antognolli
2013-06-04evas/wayland_egl: Workaround for map perspective issues.Rafael Antognolli
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.
2013-05-02revert the revert... damn you git!Carsten Haitzler (Rasterman)
Revert "Revert "Efl: replace eo_data_get for objects data referencing."" This reverts commit b64a2994b3b277cbe7fce17d7ee275fd0d78c925.
2013-05-02Revert "Efl: replace eo_data_get for objects data referencing."Carsten Haitzler (Rasterman)
This reverts commit 654a3f5f94c2464b8563d27da94a78398c112962.
2013-05-01Efl: replace eo_data_get for objects data referencing.Daniel Zaoui
2013-04-29Revert "evas/map: Consider framespace offset when populating map points."Rafael Antognolli
This reverts commit 3e43ad338d43dbe03dc401910d378aa32d84b8a7.
2013-04-13evas - Don't be crashed even if the map image size is 0.ChunEon Park
2013-04-07evas: remove one useless pointer (-30KB).Cedric Bail
2013-04-02evas/map: Consider framespace offset when populating map points.Rafael Antognolli
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.
2013-03-13evas: use Eina_Cow a lot more and we are closer to the memory size of 1.7.Cedric BAIL
2013-01-24efl/evas: don't over write when not needed.Cedric BAIL
SVN revision: 83192
2013-01-22efl: move Evas_Object map data to there own Eina_Cow pointer.Cedric BAIL
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
2013-01-21efl: group more map stuff in the same sub structure.Cedric BAIL
SVN revision: 83034
2013-01-21efl: cleanup Evas_Object_Protected_Data.Cedric BAIL
SVN revision: 83028
2013-01-15evas/map - avoid zero divide.ChunEon Park
SVN revision: 82792
2012-11-24eobj changes - protect against null eo data gets.Carsten Haitzler
SVN revision: 79635
2012-11-13evas/map - Don't extrapolate outside coords unsafely from map_coords_get()ChunEon Park
Don't know why is it actually needed. SVN revision: 79214
2012-11-13evas/map - simple refactoring.ChunEon Park
SVN revision: 79197
2012-11-13evas - return quickly if you got the result.Leandro Dorileo
Signed-Off-By: Leandro Dorileo <dorileo@profusion.mobi> SVN revision: 79196
2012-11-04merge: and now EvasVincent Torri
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
2012-10-09eo: changes made for the support of the Eo conceptDaniel Zaoui
Signed-off-by: Daniel Zaoui <daniel.zaoui@samsung.com> SVN revision: 77604
2012-09-07fix evas map leak.Carsten Haitzler
SVN revision: 76286
2012-08-31From: Christophe Sadoine <chris@indefini.org>Christophe Sadoine
Subject: [E-devel] [patch] A function to rotate an evas map with a quaternion So this is a patch to rotate an evas map with a quaternion. You can use this to avoid gimbal lock... for example in the elementary evas map 3d test, if you put the Rot y angle to 90 then Rot x and Rot z will do the same rotation... SVN revision: 75920
2012-08-12cleaning formats.Carsten Haitzler
SVN revision: 75160
2012-08-12finally found evas_map weirdness bug. CEDRIC code...! commit #74180.Carsten Haitzler
now here's the rub. from the glibc manual page: ... int memcmp(const void *s1, const void *s2, size_t n); DESCRIPTION The memcmp() function compares the first n bytes (each interpreted as unsigned char) of the memory areas s1 and s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or be greater than s2. RETURN VALUE The memcmp() function returns an integer less than, equal to, or greater than zero if the first n bytes of s1 is found, respectively, to be less than, to match, or be greater than the first n bytes of s2. ... this explicitly says that s1 and s2 have their BYTES compared... and then returns just some value < 0, 0 or > 0 based on the difference. what that value is and means is not defined, as long as it is < 0, 0 or > 0. so the C standard has this to say: 6.3.1.3 Signed and unsigned integers 2. Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type. so a result of -255 (possible) is converted by REPEATEDLY adding the max size of the new type (255) until within range... so ... -255 + 255 = 0 ... within range.. BUT FALSE! so why do we see this now? something changed in memcpy behavior. before we ONLY saw values of -1, 0 or 1 - nothing else, NOW we see thins like: -12288 49152 4096 16384 61440 -53248 so memcpy changed behavior, though within specs of the manual page anyway, but now the values can be ones that break the simple assignment. SVN revision: 75159
2012-07-19evas: try to unbork previous map fix.Cedric BAIL
NOTE: That one is nasty and I do admit that this doesn't sounds like the proper fix, but as it doesn't trigger other issue and is simple/reasonable I took to defeat that damn beast. SVN revision: 74180
2012-07-17evas: fix evas map life cycle.Cedric BAIL
SVN revision: 73963