On Mon, Nov 14, 2016 at 7:03 PM, Hermet Park <her...@hermet.pe.kr> 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
