aboutsummaryrefslogtreecommitdiffstats
path: root/legacy/evas/src/lib/canvas/evas_clip.c
diff options
context:
space:
mode:
authorCarsten Haitzler <raster@rasterman.com>2010-08-31 22:16:08 +0000
committerCarsten Haitzler <raster@rasterman.com>2010-08-31 22:16:08 +0000
commit2dedcff5d3700abb49f35257f56f1a92e9ac1f71 (patch)
treec1d773a205b70dafddbb0facb5e708608ff45ab5 /legacy/evas/src/lib/canvas/evas_clip.c
parentmove function into local, reformat (diff)
downloadefl-2dedcff5d3700abb49f35257f56f1a92e9ac1f71.tar.gz
aaaaaaaaaaaaaaargh! where's me rum! :(
SVN revision: 51788
Diffstat (limited to 'legacy/evas/src/lib/canvas/evas_clip.c')
-rw-r--r--legacy/evas/src/lib/canvas/evas_clip.c71
1 files changed, 71 insertions, 0 deletions
diff --git a/legacy/evas/src/lib/canvas/evas_clip.c b/legacy/evas/src/lib/canvas/evas_clip.c
index 6623aa718f..1de20bc1dd 100644
--- a/legacy/evas/src/lib/canvas/evas_clip.c
+++ b/legacy/evas/src/lib/canvas/evas_clip.c
@@ -38,6 +38,77 @@ evas_object_clippers_was_visible(Evas_Object *obj)
return 0;
}
+/* aaaaargh (pirate voice) ... notes!
+ *
+ * we have a big problem until now that's gone undetected... until yesterday.
+ * that problem involves clips and maps and smart objects. hooray! 3 of the
+ * more complex bits of evas - and maps and smart objects being one of the
+ * nastiest ones.
+ *
+ * what is the problem? when a clip crosses a map boundary. that is to say
+ * that when the clipper and clippee are not within the child tree of the
+ * mapped object. in this case "bad stuff" happens. basically as clips are
+ * then used to render objects, but they no longer apply as you'd expect as
+ * the map transfomr the objects to-be-clipped separately from the objects
+ * that clip them and this whole relationship is broken by maps. it somehow
+ * managed to not break with the advent of smart objects. lucky me... but
+ * maps killed it. now... what do we do? that is a good question. detect
+ * such a broken link and "turn off clipping" in that event - sure. but this
+ * isn't going to be cheap as ANY addition or deletion of a map to an object
+ * or any change in clipper of an object or any change in smart object
+ * membership needs to walk the obj tree both up and down from the changed
+ * object and probably walk entire object trees to find these and mark them.
+ * thats silly-expensive and i was about to fix it that way but it has since
+ * dawned on me that that is just going to kill performance in some critical
+ * areas like during object setup and manipulation, as well as teardown.
+ *
+ * aaaaagh! best for now is to document this as a "don't do it damnit!" thing
+ * and have the apps avoid it. but even then - how to do this? this is not
+ * easy. everywhere i turn so far i come up to either expensive operations,
+ * breaks in logic, or nasty re-work of apps or4 the whole concept of clipping,
+ * smart objects and maps... and that will have to wait for evas 2.0
+ *
+ */
+
+static void
+evas_object_child_map_across_mark(Evas_Object *obj, Eina_List *clippers,
+ Eina_Bool map)
+{
+#if 0
+ if (map)
+ {
+ // if obj->cur.clipper is in clippers list, then set
+ // obj->cur.clip_across_map to 1
+ }
+ else
+ {
+ }
+#endif
+}
+
+void
+evas_object_mapped_clip_across_mark(Evas_Object *obj)
+{
+ return;
+#if 0
+ Eina_Bool map = 0;
+
+ if ((obj->cur.map) && (obj->cur.usemap)) map = 1;
+ if (map)
+ {
+ Eina_List *list = NULL;
+
+ // FIXME: list = build list of all clippers that are children of obj
+ // up until any obj that has map applied to it. if map is applied
+ // tghen we must assume this has been run before o9n that obj and
+ // its children etc.
+ evas_object_child_map_across_mark(obj, list, map);
+ }
+ else
+ evas_object_child_map_across_mark(obj, NULL, map);
+#endif
+}
+
/* public functions */
/**