From b80b9213adc57b3e890351824cfef08b6a40de67 Mon Sep 17 00:00:00 2001
From: "Carsten Haitzler (Rasterman)" <raster@rasterman.com>
Date: Fri, 1 Nov 2019 10:12:30 +0000
Subject: [PATCH] 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);