"bring to front"
"send to back"
which is same with EVIL's PowerPoint.
Please never mind. :-P

If final value is calculated by TO_INT_ROUND, then make _edje_part_pixel_adjust
use TO_INT_ROUND for eval value as well.

Fix one more incorrect calculation.
The _edje_part_pixel_adjust could change final.w(h) value to -1.
This value is using in the _edje_part_recalc_single_rel, and has caused
incorrect position.

+2

IMO i18n (https://phab.enlightenment.org/D7506) and l10n of EFL correspond with https://www.w3.org/International/questions/qa-i18n
Now I have got difference between i18n and l10n. Thank you.

Interesting :D

I would like to want to know why eo needs 'the ability to get the size of object of a certain class' ?

+2048

Handle potential side effect

+1

I am sorry there would be a small typo.

No doubt

This is not standing for the cache2. I just quoted comment of the cache2.
This is standing for the cache.

Follow naming convention.

Update map geometry on correct place.

Check obj->map->cur.map->move_sync.enabled before doing everything

The sample is using evas_map_util_object_move_sync_set.
evas_object_map_set and evas_object_map_eanble_set are called onces and are not used whenever target object moves.
IMO the commit message would be enough. The geometry is updated only evas_render_mapped
-> evas_object_map_update
-> evas_object_map_update
-> _evas_map_calc_map_geometry is called if evas_map_util_object_move_sync_set is TRUE.

Update comment

Thank you for enlightening me.
CSD - Client side Decoration!! I thought it is standing for Child Smart Data. :-P

Please keep EFL coding conventions (https://www.enlightenment.org/contrib/devs/coding-conventions.md)

Would you please update commit message with more detailed information as @Hermet asked with separate channel?

@zmike Sure. I just would like to want to know about the upstream is handling 0 sized confiugration.
@ManMower Thank you for interesting. BTW what is the CSD?

@ManMower I am handling _ecore_wl_window_cb_angle_change which does not exist on the Upsteam now.
Tizen still has _ecore_wl_window_cb_angle_change and use def_config...
But it seems that the Tizen enlightenment does not update (not send configure) def_config. So rotated window does not show.
TBH I would like to want to know your opinion with this change.

This could be abandoned if D7030 is accepted.

Check if related file is virtualized or not

Do not allocate memory with strdup

Thank you for updates.
But I could find this usage from other places as well.
If this needs to change with eina_vpath_resolve_snprintf then it would be as follows.

In D7066#122476, @bu5hm4n wrote:

Maybe its better to use the vpath resolve variante which takes a static buffer, instead of the allocated string :)

Check if related file is virtualized or not

Fix incorrect update

Check if related file is virtualized or not

@cedric If the "when the number of user of a file goes to zero" means "file->refcount == 0" then it could become 0 when _evas_cache_image_entry_delete is called.
Please look into following summary of the "file->refcont".
(1) evas_object_image_mem_file_set -> eina_file_virtualize (file->refcount == 1)
(2) _evas_image_init_set -> eina_file_dup (file->refcount == 2)
(3) _evas_cache_image_entry_new -> eina_file_dup (file->refcount == 3)
(4) evas_common_load_rgba_image_module_from_file -> evas_image_load_file_open_dds -> eina_file_dup (file->refcount == 4)
(5) evas_common_load_rgba_image_module_from_file -> evas_image_load_file_close_dds -> eina_file_close (file->refcount == 3)
(6) evas_common_load_rgba_image_module_from_file -> evas_image_load_file_open_jpeg -> -> emile_image_jpeg_file_open -> _emile_image_file_set -> eina_file_dup (file->refcount == 4)
(7) evas_object_image_mem_file_set -> eina_file_close (file->refcount == 3)

@cedric I would like to share the issue.
An application which is works on evas gl engine calls evas_object_image_memfile_set in a timer callback.
The evas_object_image_memfile_set is using eina_file_virtualize with copy == TRUE.
This newly allocated memory is kept by the cache and never released only after the cache deletes related Image_Entry.
So memory usage becomes bigger and bigger whenever the timer callback is called.

Dear @cedric Hello. I am sorry but actually I do not have your point. Why is this not a good idea?
If the cache uses this change it could delete more image entries than before. Could this make a problem?
It would be same with reducing cache->limit.
The _evas_common_rgba_image_ram_usage(mem_size_get) calculates cache size for one process. Why did you comment regarding "shared with all other process"?
The mem_size_get counts sizeof(struct _RGBA_Image), strlen(ie->file) and strlen(ie->file). But it does not count eina_file size even though it is hold by the cache.
The allocated memory for eina_file can be released in _evas_cache_image_entry_delete only.
If the cache does not release it then a process could use 456527385 bytes (Please refer to the commit message).
If this is not a good idea then please let me know regrading better idea to solve it.

I have checked this on downstream. If there is not an objection then I would like to push this within a week.

Move the changes to proper place

Please check this with D7030

Do not multiply eina_file size

Check if image.data is null.

+1 here!

For your information Elm.Mapbuf's wd->resize_obj sets is_static_clip to true.

Fix typo

Rename test case

Add test case

@raster Thank you. If I got it correctly I need to use evas_object_image_data_get.

@zmike I have no idea how to compare two images on the unit test. Would you please let me know if you have?

Using EINA_SAFETY_ON_FALSE_RETURN_VAL to get rich information.

@raster I am on the @Hermet's page. When I got this white rectangle issue, it was too embarrassing.
Only after checking line by line and change the smelly context color, finally I could find out and I could reach this destination.
BTW what is the glitches? And do you mean that the calling evas_gl_common_rect_draw when the !tex should make nothing?

@Hermet but it gives incorrect result of image and crash as well on downstream. I can share it.

@raster Hey. Do you mean that the calling evas_gl_common_rect_draw when the im->tex is NULL should make nothing?

//It seems that the first commit of eina_vpath is following commit 1.20

Please see evas_object_inform_call_image_preloaded.

https://phab.enlightenment.org/D6740 is the unit test case for this change.

Fix a small mistake

Err... I found what I have to use. The "--with-tests"
I though I have to use "--enable-tests".

Yes but it would be hard to check using the check. If you have good idea to test please let me know.
BTW it seems that I could not execute test properly, even though I have the check.

In D6468#113075, @zmike wrote:

Okay, I understand a bit more now.

I think you have a good point, but I don't think this patch is correct.

• Why are you comparing the move function to evas_object_smart_clipped_smart_set, shouldn't you compare to evas_object_smart_clipped_smart_move?
• In the case where is_default_move is true, then this means evas_object_smart_clipped_smart_move is called twice here?
• Isn't the result the same even if you call evas_object_smart_clipped_smart_move and then the user function after?
  • I guess this would have a different result in the case where there are move callbacks set or if the user's move function was doing a relative move...
    
    So it seems to me that the correct solution to this would be instead to just ensure that the smart move function for clipped objects is evas_object_smart_clipped_smart_move if the function has not been overridden. What do you think about that?

Remove unnecessary changes.