@raster oh, didn't noticed this ticket. firstly that logic must be only working when the object enables anti_alias + smooth.. did you intend this? because normally we don't enable anti_alias option for evas objects individually,

Please check one more comment.

Please check a comment.

Please check a comment.

In D9794#182033, @tasn wrote:

I don't get this change. Readability is subjective and this doesn't read any more readable to me, and it's 20 lines longer (not that it's the only parameter, but still).
It's also hard to follow when you changed a few unrelated things in one commit (or is it just phab being bad?).

Overall looks fine to me but leave one question just in case.

Please check a comment.

Firstly,
we should not open these property apis.
These should be internal apis since there is no point to open them. Nobody could use this except efl_ui_animation_view.
So we could use some tricky method to communicate with efl_ui_animation_view.
I think we can efl_data_set()/get() to pass the data i.e.

As the current situation, separate vector objects could share a resource properly, there is not point to use vg object as the hash key.
Rather than this, current issue point is more like to canvases.

updated a comment.

interface Efl_Ui_Animation_View_Property;
class Efl_Ui_Animation_View_Lottie_Property implements Efl_Ui_Animation_View_Property;

I couldn't see any issue even though playing same resource 50 numbers.
Could you please attach sample code for this?

After considered to support property overriding,
I think we could add a separate interface i.e. efl_ui_animation_view_property
then extend per properties such as efl_ui_animation_view_property_color, efl_ui_animation_view_property_transform, efl_ui_animation_view_property_stroke, etc.
If so our efl_ui_animation_view could only suggest efl_ui_animation_view_property_override(Eo *anim_view, Efl_Ui_Animation_View_Property *prop);

Please check typos.

+ you might need to carefully check the overriding text class feature whether it's broken or not.
Launch elementary_config => Font
see API: elm_config_font_overlay_set()

I think getting part objects to check properties is not proper case as the test case.

It looks unnecessary, do we need to define one more naming => Evas_Object_Vg_Object ?

Looks this patch contains D9657 code.

@bu5hm4n Im considering use player but currentl efl_player is not satisfied with this animation_view, it might need to some adjustment but moement it has a dependencies with other components,
I don't like to change all of them and it needs some time to proper review,
Since all were in beta, we could improve them step by step , So I think you could verify this, then I will improve them from this.

All those fixed, now you could pull the enventor and enjoy it again.
This latest efl patch must be along with latest enventor.

There more serious problems to be fixed that,

In T7811#136824, @rafspiny wrote:

@Hermet Thanks for looking into this.
I can use my machine as another testbed for it when you have started working on enventor.

updated some doc syntax for c# generation.

updated some doc syntax for c# generation.

In D9451#176292, @bu5hm4n wrote:

I think the overall widget looks fine beside the fact that elm_transit is used (which is IMO not good, but i might be able to life with it :P~). However, the other topic is Efl.Player: Volume and mute can just be generally ignored and return always 0 and true. The more important part here is, that we have a unified interface for playable entities. If they are splitted, what is the difference between this play here and the play in efl_player (same applies to all the other properties)? What are we going to do to not have colliding names ?
In general, if we do not have a common ground, we cannot build up specification tests for it - we cannot build up helper classes, we are super limited in future actions we can take.

if other properties has been changed such as texture uv, image, point color, smooth option, antialiasing, etc
Does here it needs to check out all the property diff?

I tested the code history, it works fine with this patch as well.

I guess this function won't be triggered if user just make it object visible again without any map update,