Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread The Rasterman 
On Wed, 16 Nov 2016 09:55:54 -0800 Cedric BAIL  said:

> On Tue, Nov 15, 2016 at 7:00 PM, Carsten Haitzler 
> wrote:
> > On Tue, 15 Nov 2016 14:59:30 -0800 Cedric BAIL  said:
> >> On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler 
> >> wrote:
> >> > On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park
> >> >  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.
> 
> Setting path data to efl_gfx_path won't ever be a performance problem
> or other use of Eo will seriously be a problem. efl_gfx_path API is
> about defining the path, not computing it. Computing it, is what
> actually take time and ressource, by a huge factor. The API we are
> talking here does line, bezier curve, parse SVG path and so on. There
> is nothing there that should ever be costly to "set" compared to
> computing the request. The computation will be always internal, as
> object in Ector, Evas and Elementary will inherit from efl_gfx_path.

that depends how u do it. like if you do:

count = path.point_count_get();
p = path.point_get(count - 1);
p.x = 10;
p.y = 20;
path.point_xy_set(count - 1, p.x, p.y);

i mean if the api is "get small value, set it, query, etc." then you will have
an apit hat is going in and out a lot for small amounts of transaction WORK per
in and out. then the in and out costs become high.

i didnt look at any api being proposed at this point (the details) other than
purpose and name.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread Cedric BAIL 
On Tue, Nov 15, 2016 at 7:00 PM, Carsten Haitzler  wrote:
> On Tue, 15 Nov 2016 14:59:30 -0800 Cedric BAIL  said:
>> On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler 
>> wrote:
>> > On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park 
>> > 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.

Setting path data to efl_gfx_path won't ever be a performance problem
or other use of Eo will seriously be a problem. efl_gfx_path API is
about defining the path, not computing it. Computing it, is what
actually take time and ressource, by a huge factor. The API we are
talking here does line, bezier curve, parse SVG path and so on. There
is nothing there that should ever be costly to "set" compared to
computing the request. The computation will be always internal, as
object in Ector, Evas and Elementary will inherit from efl_gfx_path.
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread Cedric BAIL 
Hey Hermet,

On Tue, Nov 15, 2016 at 10:20 PM, Hermet Park  wrote:
> Cedric, I got your point.
>
> If you are worrying the bindings of path, then what about others?

Other structure don't need 20 functions to be created and populated.
Even matrix, most language come with a math package to do whatever you
want with them, the only thing really necessary is to be able to
convert those structure back to the C layout that we expect. They are
more part of the base data type you find everywhere like list, hash,
array and friends.

> I haven't planned the current eina structures bindings -  vector, matrix, 
> etc, etc.
>
> Do we have plans about it?

Do we need them in our API ? What API would be useful ? Vector, matrix
and rectangle can be treated just as a simple structure with existing
math package handling them, only C doesn't really provide that. Path
is not the same. Without this 20 API you really won't go far creating
your path. We are not talking about manipulating the path, but
filling/setting it. As you are pointing out, you plan to use this Path
information in more place in our API (Ector, Evas and Elementary),
this means exposing it as part of our core API. Either bindings have
to manually bind all the useful functions and keep track of them over
time, or it is an Eo object and the internal representation doesn't
matter to anyone. Which is actually the case.

Cedric

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-15 Thread Hermet Park 
Cedric, I got your point. 

If you are worrying the bindings of path, then what about others?

I haven't planned the current eina structures bindings -  vector, matrix, etc, 
etc. 

Do we have plans about it?

-Original Message-
From: "Cedric BAIL"<cedric.b...@free.fr> 
To: "Enlightenment developer list"<enlightenment-devel@lists.sourceforge.net>; 
Cc: 
Sent: 2016-11-16 (수) 07:59:30
Subject: Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path
 
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
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-15 Thread The Rasterman 
On Tue, 15 Nov 2016 14:59:30 -0800 Cedric BAIL  said:

> On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler 
> wrote:
> > On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park 
> > 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

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-15 Thread Cedric BAIL 
On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler  wrote:
> On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park  
> 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

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-14 Thread The Rasterman 
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).

> -Original Message-
> From: "Carsten Haitzler"<ras...@rasterman.com> 
> To: "Enlightenment developer
> list"<enlightenment-devel@lists.sourceforge.net>; Cc: 
> Sent: 2016-11-15 (화) 08:25:19
> Subject: Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path
>  
> On Mon, 14 Nov 2016 22:54:15 + Andrew Williams <a...@andywilliams.me>
> said:
> 
> > Rect seems to mirror quite well the path discussion I think - a data
> > structure vs a graphical context...
> > 
> > I see now how a non-gfx rectangle helps communicate data but can the
> > graphical react not extend data structure type rect so they are more
> > interoperable? Additionally it is strange to define these in the same
> > library as true/false and storage primitives are declared imho.
> > 
> > I wonder if we are missing a supporting gfx-structures lib that Evas and
> > many others could depend upon? And path and Rect would belong there...
> 
> no not another library. we have too many and have to REDUCE not expand.
> 
> > Andrew
> > On Mon, 14 Nov 2016 at 11:21, Hermet Park <her...@hermet.pe.kr> wrote:
> > 
> > > Eina_Rectangle  => A data structure.
> > > Evas_Rectangle => A drawing primitive.
> > >
> > > Sorry, but I thought rect is a bit digressed to this topic.
> > >
> > > I'm not a negative even though path is not going in Eina.
> > >
> > > But let's consider more realitic position.
> > >
> > > I think path is unlike to an interface but it's more to be an individual
> > > data set.
> > >
> > > And efl_gfx_shape is likely to depend on this.
> > >
> > > If you agree that it could be an interface, then efl_gfx_path may be also
> > > fine.
> > >
> > > but not in ector/evas because efl interface is lower than them.
> > >
> > > -Original Message-
> > > From: "Andrew Williams"<a...@andywilliams.me>
> > > To: "Enlightenment developer list"<
> > > enlightenment-devel@lists.sourceforge.net>;
> > > Cc:
> > > Sent: 2016-11-14 (월) 17:51:31
> > > Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
> > >
> > > I think that even if a shape is not going to be rendered it is still a
> > > graphical concept.
> > > In most frameworks I can find it is in a graphics, geometry or gui
> > > namespace.
> > >
> > > Eina is already becoming ambiguous in its purpose and adding shapes in
> > > there seems confusing.
> > >
> > > Is it just me who is confused that Eina_Rectangle and Evas_Rect both
> > > exist?
> > >
> > > Andy
> > > On Mon, 14 Nov 2016 at 02:16, Hermet Park <her...@hermet.pe.kr>

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-14 Thread Cedric BAIL 
On Mon, Nov 14, 2016 at 7:03 PM, Hermet Park  wrote:
> As considering further, we'd rather avoid path interface for the optimization 
> point.

I don't see any performance issue as most of the math and cost is into
the computation of the curve not setting a string/combo of command,
but maybe you have some benchmark in that regard ? I haven't looked at
any benchmark on our current vector stack, so you might well be right.

> 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.

Yes, it does copy a list of command and point with two arrays if I
remember correctly. Those array are pretty small and shouldn't become
that huge. If you think it might become a concern at some point, maybe
we can introduce a structure in Eina that does refcounting, allocation
and destruction (Something Eina_Safepointer should be ble to do, I
guess). No need for the path primitive to be there.

> 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.

See above proposal, that address your problem without putting pressure
on the binding generation and increasing the mess to much in eina

> Additionally, user just need to set one path data for several vg objects if 
> those vg objects may need to have same path information.

I guess, but is that a common pattern ?

> So, again, I aim to Eina again.
>
> What do you think?

As above, add arrays to a structure managed by an opaque
Eina_Safepointer that is shareable among instance of efl_gfx_path.eo.
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-14 Thread Hermet Park 
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?

-Original Message-
From: "Carsten Haitzler"<ras...@rasterman.com> 
To: "Enlightenment developer list"<enlightenment-devel@lists.sourceforge.net>; 
Cc: 
Sent: 2016-11-15 (화) 08:25:19
Subject: Re: [E-devel] FW: FW: FW: FW: Propose a Eina_Path
 
On Mon, 14 Nov 2016 22:54:15 + Andrew Williams <a...@andywilliams.me> said:

> Rect seems to mirror quite well the path discussion I think - a data
> structure vs a graphical context...
> 
> I see now how a non-gfx rectangle helps communicate data but can the
> graphical react not extend data structure type rect so they are more
> interoperable? Additionally it is strange to define these in the same
> library as true/false and storage primitives are declared imho.
> 
> I wonder if we are missing a supporting gfx-structures lib that Evas and
> many others could depend upon? And path and Rect would belong there...

no not another library. we have too many and have to REDUCE not expand.

> Andrew
> On Mon, 14 Nov 2016 at 11:21, Hermet Park <her...@hermet.pe.kr> wrote:
> 
> > Eina_Rectangle  => A data structure.
> > Evas_Rectangle => A drawing primitive.
> >
> > Sorry, but I thought rect is a bit digressed to this topic.
> >
> > I'm not a negative even though path is not going in Eina.
> >
> > But let's consider more realitic position.
> >
> > I think path is unlike to an interface but it's more to be an individual
> > data set.
> >
> > And efl_gfx_shape is likely to depend on this.
> >
> > If you agree that it could be an interface, then efl_gfx_path may be also
> > fine.
> >
> > but not in ector/evas because efl interface is lower than them.
> >
> > -Original Message-----
> > From: "Andrew Williams"<a...@andywilliams.me>
> > To: "Enlightenment developer list"<
> > enlightenment-devel@lists.sourceforge.net>;
> > Cc:
> > Sent: 2016-11-14 (월) 17:51:31
> > Subject: Re: [E-devel] FW: FW: FW: Propose a Eina_Path
> >
> > I think that even if a shape is not going to be rendered it is still a
> > graphical concept.
> > In most frameworks I can find it is in a graphics, geometry or gui
> > namespace.
> >
> > Eina is already becoming ambiguous in its purpose and adding shapes in
> > there seems confusing.
> >
> > Is it just me who is confused that Eina_Rectangle and Evas_Rect both exist?
> >
> > Andy
> > On Mon, 14 Nov 2016 at 02:16, Hermet Park <her...@hermet.pe.kr> wrote:
> >
> > > elm_path well..  it's not a concreted idea yet, but we may provide that
> > > kind of feasible object like a elm_flip for an arbitrary shaped objects.
> > >
> > > I don't know about elm_chart but guess it does not have a simliar concept
> > > with path object.
> > > Because the traditional charts have been designed for a sort of vector
> > > wise graphical drawing like lines, bars and *pizza* pies etc.
> > > but this path is majorly designed  for binding our graphcial objects onto
> > > an arbitrary path.
> > >
> > > See the next some screenshots.
> > >
> > > https://phab.enlightenment.org/F48119
> > > https://phab.enlightenment.org/F48120
> > > https://phab.enlightenment.org/F48121
> > > https://phab.enlightenment.org/F48122
> > >
> > > If you have more than the chart idea than I expected then please share it
> > > to us.
> > >
> > > Also, I don't see extending efl_gfx_shape is not the answer here.
> > > If path object is introduced in elm, path won't need all shape stuff.
> > > Even some usage may just require only path data without graphical
> > drawing.
> > > So rather than that, modulization(divide path) should be considerd for
> > > shape now.
> > >
> > > Honestly, I'm not quite sure which place is the best for the path
> > > interface but at least Eina for now.
> > > Even necessary of path eo binding. of course, path naming could be
> > > co