In time, maybe, but not necessarily. I have some idea that can be explored on using proxy instead of map. Depends. Anyway, that is for later.
@cedric I think you need to lay off the baguettes. I only did optimizations for mask and proxy renders, not map. Do...do I have to look at map too?
Mon, Aug 19
Sun, Aug 18
The basics are there. The accessing is still quite rough.
The basics of the Group feature are now available (Revisions linked to T8115).
The problems in there are that the accessing of the group is quite rough and tiresome, i am not happy myself with it. But i am thinking that its important to have at least a state, so we can look into performance and *feeling* as well.
Sat, Aug 17
Fri, Aug 16
@cedric do you think you will ever be interested in the group item of the first item in the size callback ?
Tue, Aug 13
Enjoy your vacation! The idea is to group together a bunch of object that move together in one smart object that we can turn evas map on. This way they become automatically buffered and it will speed up scrolling. But we do not want to put into a group things that would be resized or moved differently. The Position Manager being the only one who knows, we need a way to tell the Collection how to group things.
I still fail to understand what exactly needs to be done here, can you give a brief explanation what is expected, in what form, at which occasion?
Mon, Aug 12
I was requested this feature from the tizen developers several times but at that time we couldn't have enough time to fix it so reject the request but if we can do this, it will improve scrolling performance very well.
I think it need to be 3 buffer for this, one is in the viewport and others are for the top and bottom....
Not necessarily as with Group you need to know which object the Position Manager might move differently.
Oh, but wouldn't that also just work if you take the range that is passed via the event and use the API that the collection (view) passes to the position manager for batching ?
The same slice trick.
What do you mean with buffer here ?
Thu, Aug 8
yes. we can go with current group index.
Wed, Aug 7
I think the problem with the item side is that we have a API which allows arbitary position of the items, but the grouping also puts a rule of positioning onto it, feels like a little bit racy. For getting around that we could ensure that in Efl.Ui.Collection we only accept items that are not grouped. After that, we can add API to the group item, for adding items as its children, which are then propagated *somehow* to the Collection. (I am not sure how much this is needed in Collection_View)
Tue, Aug 6
Thu, Aug 1
As I am working on Efl.Ui.CollectionView at the moment, I do absolutely plan to use this for handling all data. CollectionView shall not have any internal state related to any Item. It does completely break the design if we start to have random data not in the model as we can then not rely on MVVM infrastructure to use them.
vpaths looks like a very convenient thing to have. We should also be consistent, so if we allow them in some APIs, we should allow them everywhere. This seems to be already the case, as @bu5hm4n said, right?
but the who will be managing the data? view itself? or viewmodel should?
we have statesmodel in the elementary,
I'm not sure we have plan to use them.
Wed, Jul 31
That is already the case (efl_file.c:96).
Sat, Jul 27
Right now we have m calls to the accessor, which are direct calls, with a batch oriented system we would have 1 call, but we iterate 2 times over the m items, first we copy everything into the buffer, and later on iterate again over the buffer to read it out.
In case of the object placement in list, i am also not sure if it would only be one call to request a buffer, since its not clear when we are stopping to place items, so it also might be multiple calls.
A few more things :
- I see one issue with your idea of getting the context from the accessing scheme, a position manager can request whatever items it likes to, and you might need to request items that are not even visible. IMO the logic to realize this tracking is way more complex than the current _get_at function.
- The logic for "keeing the buffer a little bit arround" makes me a little bit nervous, heavy scrolling or some animation that does scrolling might request a lot of batches, wouldn't that mean we explode memory wise for that time ?
- The reason the _get_at function in collection is looking how it looks, is to avoid eina_list_nth calls, because they are terrible slow. Even if you have the batch requesting, you will still want to have some caching mechanism like we have it right now in the _get_at function, which would bring that complexity from _get_at also into the batching, so this is not a real win (win over your first reason).
- I do not understand why you are saying that a slice is saving memory and reduces the memory allocation, we currently do 0 memory allocations when placing items, but with the batching we would need to allocate at least 1 buffer?
Fri, Jul 26
After a bit of work for CollectionView, I am pretty convinced that Accessor are a bad solution here.
Jul 19 2019
This is why we do have the Efl.BooleanModel and Efl.SelectModel.
@cedric @felipealmeida @bu5hm4n
as my understand, our efl_view_model or efl_ui_state_model need to take control some ui-related boolean states in the model data.
select/unselect (by interally adding select_model)
Jul 10 2019
Jun 30 2019
@cedric you can find my current implementation in https://git.enlightenment.org/core/efl.git/log/?h=devs/bu5hm4n/work_container
Jun 28 2019
So we will be going with @bu5hm4n solution. He has already build more code around it and I don't see anything wrong with it.
Hum, I was going for a very different approach actually. I was thinking of having a function to call on a object with something like :