On Tue, 15 Nov 2016 14:59:30 -0800 Cedric BAIL <cedric.b...@free.fr> said:
> 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).
if you want to move all the other stuff form eina to efl_gfx - fine. well that
means duplicating it to keep abi. rects, matrixes, vectors etc. but you still
have the problem that apis are higher cost with eo so the c costs of messing
with paths beyond higher level (here is an array of points - deal with it" will
be there. if all the apis are very high level then this cost is not such a bad
thing. it depends on the api really.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
