Could u please check a comment?

Could you please check my review?

impossible this?

update load_size_set;

Destructor doesn't mean evas_object_free();
All will be freed after evas_object_free() and that would be called after delete_me == 2;

updated commit msg.

there is MAGIC_CHECK() already. adding this additional one is too much. I think we can remove MAGIC_CHECK there.

@raster let's forget preloading. Acutally, !tex shouldn't be happened, but let's assume the exception case. Developers will be more embarrassing If something solid color rectangle showed up. Because they more likely to think some obstacle objects(i,e rectangle eo) may be onto the image. Only few core developers who exactly know this exceptional handling in this backend engine could understand but not others. Even I firstly guess somewhere dangling white rectangle, clipper or image objects were there but not this (!tex) case. More than this visual, ERR message is more clear.

Let's assume Neon is stable, I think Neon in EFL has been used many years.
I could bet on this idea *IF* average performance of using Pixman is better than our pure efl rasterizer.

updated commit msg.

rebase

@raster, This situation is in the image preloading. Both are abnormal situation though but IMHO, engine should not do this unexpected visual result. If unexpected situation(no texture) comes, it's better to leave to users fill there with what color or what bg images (of the this texture content). Apps don't allow this embarrasing rectangle come out. For debuging, we can just print message there.

In D6739#116442, @zmike wrote:

Hm I think @kimcinoo is saying that with this code it appears to be possible that both preloading and preloaded are true. This appears to be the case if an image is preloaded (evas_object_inform_call_image_preloaded) and then another preload is set (_evas_object_image_preloading_set) before pre-render is called. Can you verify this case?

It doesn't affect anywhere though because preloading is prior to preloaded. If preloading is true, render_pre() just exits the rendering whatever preloaded is true or not,

beta but since 1.21?

In D6739#116363, @kimcinoo wrote:

Please see evas_object_inform_call_image_preloaded.

It calls
(1) _evas_image_load_post_update -> preloaded: TRUE, preloading: TRUE

it does _evas_image_load_post_update -> preloaded: TRUE, preloading: FALSE;

(2) _evas_object_image_preloading_set -> preloaded: TRUE, preloading: FALSE

True but preloaded is only available when preloading is false.

IMO above order need to be changed in 'preload*'s point of view.
i.e. whenever the 'preloaded' is set to TRUE, the 'preloading' should be set to FALSE.

Currently it does.

Please add proper reviewers; there is a genlist maintainer.

In D6725#115817, @zmike wrote:

Do you have an example case for this or is it just when no file is set?

fix coding convention.

elementary image: don't calc size using empty ones.

In D6693#115148, @zmike wrote:

Is this even used?

We can't accept this situation. resize_obj must be valid if obj were still active. It a failure case of synchronousing both 2 objects. We must deep look and fix root cause.

Btw, color class description.... just curious which case we can utilize this functionality?? (except edje_edit)

This fix actually submitted by @raster

will review/push after 1.21,

If here efl_invalidation is neccesary, It' s really serious at efl. We can't add all this kind of stupid exceptional handling.
It's hard to expect when we need to check efl_invalidated_get() in function. Even right moment. Whatever this may fix some errors, we should not do this.

@SanghyeonLee Could u please review this patch?

@zmike Could u please more clear this sentence? "So I think the patch should be changed to just copy in the second part of the function."

let go of this after 1.21 release.

We can't apply this yet unless there is json load.
Just keep it here and see.

the regarded patch has been submitted.