On Tue, Nov 15, 2016 at 7:00 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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.
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
