Hmm does this work for smart objects source ?
Very simple solution to fix this issue, user can set the source object as scroller viewport object, not the origin content.

Please check comments.

Previously, was this feature was supported correctly?

This interface will be worthy when player supports this sector playing,

Please check comments

Some comments

Please check a comment.

Please check comments.

a simple comment.

Please check comments.

it's shame that i couldn't make it to go to edd 19, at least i tried to send one rendering guy here for sharing working core tasks but it didn't work.

Please carefully test and push it if no any compatibility breaks.

I think you can refer how we apply the matrix transform for the nodes...
Alpha needs exactly the same method.

Please check a comment.

Considered the case, it's unnecessary cache it since it won't be shared with any others.
How about this ?
evas_cache_vg_entry_create(Evas *evas, const Eina_File *file, const char *key, int w, int h, Eina_Bool cacheable);

You argue the issue comes up with threading but there is no any thread synchronization methods for the thread safety. The fundamental problem must be still alive.

good!

The thread work is supposed to draw with the previous context, (before engine set).
But this fix still ignores it but keep the thread to draw with new engine info.

Still we need a method to notice vg to update it if the value provider is changed, but we can improve this later.

Please apply this after 1.23 release

One more comment.

Looks fine to me please apply this after 1.23 release.

Don't just copy & paste.
If something wrong or unnecessary, you don't need to keep the consistency.

I think we can apply some leak fixes but i don't agree on this removing parent set.
Please check my comment and give me your opinion.

Please check one comment.

Please check one more comments.

Please check comments.

Overall assembled code looks fine to me some unnecessary debugging prints just bothers other developers to checking logging. (except it occurs performance drop);

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

thought again with canvas vg altogether,

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);