In D9260#171930, @segfaultxavi wrote:

With its current functionality, I think this class should be named Efl.Ui.Text_Circle and the property should be radius.

Or is this widgwt capable of drawing other shapes? @Hermet? @zmike? @bu5hm4n?

Could you please attach an actual issue example in the code?

Please check a comment.

added deprecated flag

@kimcinoo Sorry, screwed up the patch by mistake, please see https://phab.enlightenment.org/D9313

moved deprecated api to elm_deprecated.
and added @deprecated tag.

Please check comments.

Please check comments.

Please check comments.

Though it's workaround, i think it's better than the current.

@cedric There were not any issues, Tizen has supported android 9 patch since 2012. (even we couldn't support margin area)

@smohanty any special purpose for this? efl is going to integrate one unified set.

Maybe we can replace xref with just efl_ref()

We'd rather put logs in api so that user know which api they misused.

Does it need to redraw children of mapped object? or below object of the map object?

Do we really need to make it compatible with Android fully or just only for major usage?
Yet I've never seen practical images, that containing multiple stretchable regions, used.
And I'm worrying it just increase complexity in several points unnecessarily, maybe just 9 case is enough.

Please check my comment.

Worring about how much this would decrease the loading performance than original one practically.
We cannot recommend use this 9 patch feature if it's worse than others...

As @zmike mentioned, It's hard to catch the point at this patch, what is exactly issue here why this handling is required....

There are a lot of calls, is it wrong?

this c implmentation could be compared with simd implementation.
So, hjust leave it as it does, even memcpy() is not better than current one.

Fundamentally the behavior is nothing different with border_get()...
Later, will you return the actual pixel data region? or just geometry region?

Maybe I could change furthermore.

In D9085#167024, @kimcinoo wrote:

Honestly I do not get what "Currently growbuf == outbuf is out of date." is. Do you mean that the outbuf is out of date, because it is same with growbuf? And is that for the first case that the outbuf is not dirty?

(1) If the condition "(inbuf != outbuf) && out->dirty" is false, then " growbuf == outbuf" and it will work as below.

blur_add(inbuf, growbuf(outbuf)) -> curve_add(growbuf(outbuf), tmp) -> blend(tmp, outbuf)
(i.e.) inbuf -> [Blur] -> growbuf(outbuf) -> [Curve] -> tmp -> [Blend] -> outbuf

(2) If the condition "(inbuf != outbuf) && out->dirty" is true, then " growbuf == tmp" and it will work as below.

blur_add(inbuf, growbuf(tmp)) -> curve_add(growbuf(tmp), tmp2) -> blend(tmp2, outbuf)
(i.e.) inbuf -> [Blur] -> growbuf(tmp) -> [Curve] -> tmp2 -> [Blend] -> outbuf

Without this patch each step could be following.

inbuf -> [Blur] -> growbuf(outbuf) -> [Curve] -> growbuf(outbuf) -> [Blend] -> outbuf
inbuf -> [Blur] -> growbuf(tmp) -> [Curve] ->growbuf(tmp) -> [Blend] -> outbuf

Then can we use the outbuf in these cases?

Please check a comment.

Please check a comment.

Please check a comment.

And this doesn't initialize alpha but default color.

And It's very suspicious at this condition.

Please check my comment.

While reading evas_filter_command_grow_add(), it could generate temporary buffer in a specific condition,

Please check a comment and give me your opinion.

Please check a comment.

Please check comments.

Please check comments.

updated as reviewers' comment.

update code.

Please check a comment.

Actually, Evas_GL_Image could be shared among images as it's optimal, what makes texture loading fails?