Hi, thank you for coming back to this.
As a general note:

HI :) I did a little check to solve this.
I understand why you should replace void * with array <> or iterator <>....
However, efl_gfx_path uses the data transmitted as parameters from user side and does not manage path memory separately.
If this is changed, the user who has used the existing API or the legacy API must create and pass the array type data. or legacy path apis manage to array memory.
I think, we are not ready for that yet. The path is used in many places.

will have a look.

Let's close it :)

I played just a bit with the gifs like it happened to me before and I don't see the flickering anymore... bug fixed? :)

This is working now. Fixed by commit https://git.enlightenment.org/core/efl.git/commit/?id=13ecc4898c23aa58421a847efbe5392d2b18cef8

For the record: I have a svg icon theme.

I think this is fixed by the svg fix you provided. I cannot reproduce this anymore.

Possible way to track it down is to run enlightenment under Xephyr by passing -massif to enlightenment_start and try to reproduce it that way. It should give deeper meaningful trace and associate it with timing information that could lead to an understanding of what is going on. It might be linked to specific engine configuration like texture mapping stuff.

I have been running expedite under massif and only found a leak in the VG part. Nothing that would explain enlightenment leak.

I expected this to be from the cursor idle animations, but I created a test app to simulate it and after an hour or so there were no leaks.

@stefan_schmidt I tested this with everything updated this morning. It works just fine when using software rendering, however when I try to test with gl rendering, nothing works .... not even elementary_test :( so I am unsure what to do here.

@stefan_schmidt Yes, I am actively looking into this. Apologies for missing your message on the 13th, but for some odd reason, I did not get a Phab email about it :(

@devilhorns ping

@devilhorns as our remaining wayland expert could you please check on this? Reproduce this with latest efl and weston and see if you can find a fix?

@Hermet

ping?

I have no further complains regarding documentation. Was the code ever reviewed? @Hermet ?

reword

rename to has_fixed_size

rename to has_fixed_size

The requirement is that it does not change size, this is true, but the fully optimized render path requires that it does not change size or move. For some cases moving will not affect the speed, but it requires some deep knowledge of render internals to be able to make that distinction.

Indeed, I missed that.

In D8918#166164, @cedric wrote:

In D8918#166114, @zmike wrote:

This only loads the texture if it has previously been prepared for drawing. In the given scenario, this codepath is triggered during object construction and so no such preparation has occurred.

Hum, I am guessing that in this case, there isn't any texture available, maybe not even a valid width, height and color space. Maybe do a test on the texture and switch between the two possible function for creating image. As @Hermet pointed out, I am also afraid that the new_from_rgbaimage will either leak a texture if one is available or duplicate image.

In D8918#166114, @zmike wrote:

This only loads the texture if it has previously been prepared for drawing. In the given scenario, this codepath is triggered during object construction and so no such preparation has occurred.

In D8887#166127, @zmike wrote:

I'm not so sure about dropping clipper from the name; this functionality only exists for objects which are clippers, so shouldn't the naming indicate this?

In D8887#166125, @segfaultxavi wrote:

Thanks for the context!

has_fixed_size looks fine to me as a property name. If it is moved to the clipper object then the clipper_ part of the name needs to be dropped, obviously.