Here is a my performance comparison. Here number indicates the elapsed time(ms) for performing map drawing

In D8106#147127, @raster wrote:

what's the performance difference on a range of devices/architectures?

Originally, the unpack/unset objects have been just left as the dangling objects though the behavior is not correct.
We should make the behavior policy for those dangling objs to connect to a new parents and IMO, the most top object(window) is the right one .

clean up code.

In D8106#145553, @cedric wrote:

Neat. It would be great if that could become a flag on efl_gfx_mapping.eo (I can imagine, for example, that during animation we would be fine to drop precision and just turn it on at the end of an animation). Anyway, this patch can not land at this point in time, remind me to do a better review after the release.

clean up code.

clean up code.

Hard to say which one is better, even hardly distinguish the differences.
But as far as I checked, as slices=maximum, the visual comes better with this patch.

changing rounding stuff is ok to me but wondering why introduce additional condition (params->final.w/h > 0) there...

Logically, it's fine to me, let's accept this one unless any side effect is detected.

@jypark Is it possible to make a sample as a unit test to verify the error scenario?

one comment. please check.

Sorry, I couldn't check this report, I will check this issue soon.

using round there looks fine but the modification of round function doesn't look right to me.
That is only valid for decrease case in negative values. increment in negative will be incorrect.
IMO, just leave round up as it does would be fine...

Looks something wrong about color,
there is still an implemenation of _efl_ui_win_part_efl_gfx_color_color_set()/get(), _efl_ui_wi_efl_ui_win_part_efl_file_file_set()/get()
Guess they could be used or remove the bodies additionally.

In D7769#138096, @segfaultxavi wrote:

I agree Image is not correct, but I think Frame is too generic. It is not clear what it is being controlled by this class.
I liked Efl.Gfx.Animation_Controller. Are there any other opinions?

not yet confirmed

Please check comments.
we need replace all image objects to animated object in the doc.

I think we could remove animated prefix here,

It seems the callback_register/unregister shouldn't be in Evas_Canvas3D if they are only used in Canvas3D Node so far.
Yet we have no scenarios by derived classed, there is no reason to be interface nor pure virtual function.

I propose to change the name of efl_gfx_image_animation_controller to efl_gfx_frame_controller since "frame" could be commonly used then "image",
This interface must be designed to control sort of "scene", just normal "image" or something continous vector data...
Any feedback is welcome.

How about just efl_gfx_frame_controller ? (remove animation)

Please see comments.

Added comments.

This patch is managed in devs/hermet/lottie

This patch is managed in devs/hermet/lottie branch.