raster pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=b80b9213adc57b3e890351824cfef08b6a40de67
commit b80b9213adc57b3e890351824cfef08b6a40de67 Author: Carsten Haitzler (Rasterman) <[email protected]> Date: Fri Nov 1 10:12:30 2019 +0000 Revert "elm/genlist: don't process entire item queue on each item add" First - the big problem. This breaks enlightenment's bluez5 popup. it does a sortyed inert using the item data and the item data for one of the itmes to compare in _cb_insert_cmp() in e_mod_popup.c when it calls elm_object_item_data_get(0 returns a junk ptr for the item data after this patch. i haven't managed to figure out exactly why in my last 30 mins of looking. But a closer look... this disables immediate processing of: 1. the first block of items (32items) which was intended so for short/small lists you have some content by the time you go to the first frame, and at least the first block of itso you seem to have visual contnt and not a blank list until idlers can process further content. so the patch being reverted would have gotten rid of this logic that gets you content as opposed to blank: while ((sd->queue) && ((!sd->blocks) || (!sd->blocks->next))) 2. if it's a homogenous list, all items have the same size so we do have to realize the first item of each class type but ONLY that one. further items should not need realizing as we can ASSUME the height to be the same as the first item... that's the point of homogenous + compress lists - all items of the same class have the same height and width thus shortcutting further need to calculate nd realize. if we are reizing everything in a homogenous list then the issue lies with something going wrong with this above logic. we shokuld be able to handle such lists super fastif this logic was working. that's the 2nd while: while ((sd->queue) && (sd->blocks) && (sd->homogeneous) && (sd->mode == ELM_LIST_COMPRESS)) so overall, this should not have been realizing every item. either just the first block of 32, OR just the first item of any class and thus assume all further items are the same size without realizing being needed. if these broke then the solution is not commenting this out but finding out why this logic is breaking :) and not to mention... this commenting out also caused segfaults in existing applications which are doing the right thing. perhaps the sorting logic also needed updating as well if this above is commented out... but i didn't have time to chase it more than this. --- This reverts commit 0777b74f07857c86408bc0929e3391ced0e098e4. --- src/lib/elementary/elm_genlist.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/lib/elementary/elm_genlist.c b/src/lib/elementary/elm_genlist.c index be32ca4948..9f2fb8e4a0 100644 --- a/src/lib/elementary/elm_genlist.c +++ b/src/lib/elementary/elm_genlist.c @@ -4929,7 +4929,6 @@ _item_queue(Elm_Genlist_Data *sd, // FIXME: why does a freeze then thaw here cause some genlist // elm_genlist_item_append() to be much much slower? // evas_event_freeze(evas_object_evas_get(sd->obj)); -/* while ((sd->queue) && ((!sd->blocks) || (!sd->blocks->next))) { ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del); @@ -4941,7 +4940,7 @@ _item_queue(Elm_Genlist_Data *sd, ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del); _queue_process(sd); } -*/ + // evas_event_thaw(evas_object_evas_get(sd->obj)); // evas_event_thaw_eval(evas_object_evas_get(sd->obj)); evas_object_geometry_get(sd->obj, NULL, NULL, &w, NULL); --
