summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCarsten Haitzler (Rasterman) <raster@rasterman.com>2019-11-01 10:12:30 +0000
committerCarsten Haitzler (Rasterman) <raster@rasterman.com>2019-11-01 10:23:40 +0000
commitb80b9213adc57b3e890351824cfef08b6a40de67 (patch)
tree4422c8f7b565eb15a743b7c029de7783b85897ba
parent39bde2cedf2ea87b18e38a7df757425e24ffe70f (diff)
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.
-rw-r--r--src/lib/elementary/elm_genlist.c3
1 files changed, 1 insertions, 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,
4929// FIXME: why does a freeze then thaw here cause some genlist 4929// FIXME: why does a freeze then thaw here cause some genlist
4930// elm_genlist_item_append() to be much much slower? 4930// elm_genlist_item_append() to be much much slower?
4931// evas_event_freeze(evas_object_evas_get(sd->obj)); 4931// evas_event_freeze(evas_object_evas_get(sd->obj));
4932/*
4933 while ((sd->queue) && ((!sd->blocks) || (!sd->blocks->next))) 4932 while ((sd->queue) && ((!sd->blocks) || (!sd->blocks->next)))
4934 { 4933 {
4935 ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del); 4934 ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del);
@@ -4941,7 +4940,7 @@ _item_queue(Elm_Genlist_Data *sd,
4941 ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del); 4940 ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del);
4942 _queue_process(sd); 4941 _queue_process(sd);
4943 } 4942 }
4944*/ 4943
4945// evas_event_thaw(evas_object_evas_get(sd->obj)); 4944// evas_event_thaw(evas_object_evas_get(sd->obj));
4946// evas_event_thaw_eval(evas_object_evas_get(sd->obj)); 4945// evas_event_thaw_eval(evas_object_evas_get(sd->obj));
4947 evas_object_geometry_get(sd->obj, NULL, NULL, &w, NULL); 4946 evas_object_geometry_get(sd->obj, NULL, NULL, &w, NULL);