+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.

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.

Use correct function evas_object_smart_clipped_smart_move to compare.
Handle condition following condition

Something is wrong :-(

Please do not overlook users such as https://phab.enlightenment.org/D6696

err.. I could not push because of following error.

At first the _efl_ui_win_efl_gfx_entity_size_set is called before _efl_ui_win_show.
But the second evas_object_show(win) does not make _efl_ui_win_efl_gfx_entity_size_set be called.
So first_draw is not changed. As a result, the frame_object is not visible at the second show.

Is the _efl_ui_win_efl_gfx_entity_size_set called before _efl_ui_win_show?

For your convenience, please refer to following sample.

Oh pong~ Sorry for this late pong :-( I'm too lazy. Spank.. Ah~ :-0