A correct way(https://phab.enlightenment.org/D8618) is coming

The following is commit message. This could explain more about the issue.

@shilpasingh is it not possible to add test case to efl/src/tests/elementary/efl_ui_test_atspi.c ?

I would like to merge this soon. The test case could be added by separated patch set (@bu5hm4n)

+1

Rebase

Remove change not related to use of TO_INT_ROUND.

"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