I have no idea how this api is guaranteed for it's purpose... if It's unlikely work as you purposed. How user guarantee clipper won' be changed?...

I find the name confusing as it seems it has confused everyone who looked at this patch. What about clipper_static_size? @segfaultxavi an opinion on the subject?

It is indeed confusing having vars named is_static_clip and clipper_is_static in two different structures (_Evas_Object_Protected_Data and _Evas_Object_Protected_State).

First off, if this is a property of the clipper, why is it added to the clipped object instead of the clipper?
The code for _efl_canvas_object_efl_gfx_entity_size_set already shows how cumbersome this is since a clipper has to walk its list of clippees to see if any of them considers it to be static.

Regarding the API names, if both (legacy and new) are to be kept because they really have different meanings, this difference has to be explicit: clipper_has_static_size, clipper_has_fixed_size, clipper_is_unresizable...
Ideally, we would also rename the legacy API but we cannot.

Also, can both flags be moved to the same structure?

It seems like there's some confusion about this API, so I'll try to explain the concept a bit better so that we can have a good discussion.

The purpose of this functionality is to provide a method of informing render internals that a given clipper's size will not change. This is important for the purpose of mask and proxy rendering because both of these create an intermediate surface (hereafter P) to draw the mask/proxy onto before rendering the final result onto the object's real surface (hereafter R). In the case where the proxy/mask is clipped to a size smaller than this real surface (and, for proxies, in the case where another proxy is not sampling from this proxy), the size of P can be reduced to the visible area in order to provide significant improvements to both memory usage and performance.

As far as naming goes, perhaps clipper_has_fixed_size is the best?

The property could indeed be moved onto the clipper object; I'll wait to do any revising until the naming is decided upon. I will not, however, make any changes to the legacy API or implementation.

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.

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.

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?

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.

ping?