On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park <her...@hermet.pe.kr> > said: >> As considering further, we'd rather avoid path interface for the optimization >> point. >> >> Current downside of the evas_vg, it needs to copy the path data to the ector, >> since both ector and evas_vg inherit gfx_shape. >> >> But If the path is an independent instance, >> it's possible that evas_vg just pass the path instance to the ector with the >> ref count increase. Plus, ector and evas_vg track the path changes flexibly. >> >> Additionally, user just need to set one path data for several vg objects if >> those vg objects may need to have same path information. >> >> So, again, I aim to Eina again. >> >> What do you think? > > it already has rectangles, and "tile buffer" which is really a rectangle > "update region" system which are really just data structures. it has matrix > stuff which frankle is used 90% of the time for gfx. quadtrees are data > structs > almost exclusively used for gfx (2d regions/arrays of stuff). it has vectors. > gfx. eina has a lot of "basic gfx related data types" in it. i don't see > another lib as being useful here. another lib simply adds MORE problems. we > have issues already where we have SO MANY .so's on some systems efl fails > because we cant dlopen more libs at all. ran out of __thread slots. this is > not > an optimization. it's a real bug that we cant solve without either: > > 1. telling people to upgrade.patch libc > or > 2. us reducing the number of .so's we have. > > forget optimizing. we need to do this just to stop having things fail > entirely. > dont add another lib that then has to be merged anyway. > > now to naming... i dislike eina_path - like many i think of file path first, > not gfx path. if anything maybe call it eina_shape? or eina_outline or > eina_poly? (polygons, beziers - just be rough and call them polyline/curve > segments).
As said before, if you want to have the structure defined in Eina as a data structure, maybe, but the entire API, the 20 functions that cover path in efl_gfx_shape.eo, should remain in an eo object due to bindings. It makes absolutely no sense to expose all this operation as just a C API when we are manipulating an object that needs to be accessible with no integration in every language. For once, this is right in Eo as it is a useful API in every binding that has no reason to be manually binded. Which get me back to my proposal, move them to efl_gfx_path.{eo,c} and use add a function to share the array between two instance of efl_gfx_path without any cost (This is something that can stay completely internal and the structure of the internal data doesn't need to be exposed). -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel