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
