From 5eb1f78081ed6017a360f2e24c264984406525dc Mon Sep 17 00:00:00 2001 From: Timothy G <22472919+GTimothy@users.noreply.github.com> Date: Tue, 12 Jan 2021 13:24:54 +0100 Subject: [PATCH 1/2] Create Lazy_Finite_or_Infinite_data_in_Widgets.md --- Lazy_Finite_or_Infinite_data_in_Widgets.md | 64 ++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Lazy_Finite_or_Infinite_data_in_Widgets.md diff --git a/Lazy_Finite_or_Infinite_data_in_Widgets.md b/Lazy_Finite_or_Infinite_data_in_Widgets.md new file mode 100644 index 0000000..a8b2d7c --- /dev/null +++ b/Lazy_Finite_or_Infinite_data_in_Widgets.md @@ -0,0 +1,64 @@ +# Lazy Finite or Infinite data in Widgets. + +## Summary + +A `Dynamic_Data_Wrapper(Vec)` than can fetch more data/trim its content based +on received messages `FetchPrevious(how_many)`, `FetchNext(how_many)` / an update + call. + +Solves: + * Both Lazy Finite and Infinite `Scrollable` + * Both Lazy Finite and Infinite anything that uses a `Vec` + * Lower computation cost in both cases: Lazyness => smaller widget lists in + scope => fewer primitives calculated and simpler/quicker layout calculations. + + +## Motivation + +Solves: + * Both Lazy Finite and Infinite `Scrollable` + * Both Lazy Finite and Infinite anything that uses a `Vec` + * Lower computation cost in both cases: Lazyness => smaller widget lists in + scope => fewer primitives calculated and simpler/quicker layout calculations. + + +1. In Iced, large amounts of widget lists may cause performance issues due to the +nature of update, draw, layout and view methods, even when many widgets are out +of view, if states change. + +2. In Iced, I have not found Infinite list implementation where the +very large/infinite list is only loaded partially when receiving requests. + +Seeing as 2. usually leads to 1. I propose a `Into>` Struct that +updates (grows, trims) an inner `Vec` when requested. That `Vec` is + used as usual (transparently) by other widgets, like `Columns` and `Rows` for example + by implementing `Into>` on this wrapper (or From?). + + +## Detailed Explanation + + +A `Dynamic_Data_Wrapper(Vec)` than can fetch more data/trim its content based +on received messages `FetchPrevious(how_many)`, `FetchNext(how_many)` / an update + call. + +Has a mutable buffer_size to let us choose how much to keep: +* when at maximum capacity, `FetchPrevious(n)` pops `n` end values and inserts `n` +new values at the start +* when at maximum capacity, `FetchNext(n)` pops `n` start values and appends `n` +new values at the end. + +Implement `Into>` by returning its current contents. + +Has an `OrderBy` trait that forces the Developper to define how to fetch more +items (basically to now what **previous**, and **next** items are). + + +Systematically appends an additional "Load more" widget (stylable) at the end of the +content which can be triggered to send a message to the DDW to ask it to load more content, for +instance when GUI-interacting on it, or programmaticaly. + +Systematically inserts an additional "Load previous" widget (stylable) at the start of the +content which can be triggerd to send a message to the DDW to ask it to load more content, for +instance when GUI-interacting on it, or programmaticaly. + From 2f97160c945b73f19906bbfef6bf610c76aa30cd Mon Sep 17 00:00:00 2001 From: Timothy G <22472919+GTimothy@users.noreply.github.com> Date: Wed, 13 Jan 2021 19:24:12 +0100 Subject: [PATCH 2/2] Update Lazy_Finite_or_Infinite_data_in_Widgets.md focus the approach on the data rather than widgets. --- Lazy_Finite_or_Infinite_data_in_Widgets.md | 42 ++++++++++------------ 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/Lazy_Finite_or_Infinite_data_in_Widgets.md b/Lazy_Finite_or_Infinite_data_in_Widgets.md index a8b2d7c..595e593 100644 --- a/Lazy_Finite_or_Infinite_data_in_Widgets.md +++ b/Lazy_Finite_or_Infinite_data_in_Widgets.md @@ -2,15 +2,15 @@ ## Summary -A `Dynamic_Data_Wrapper(Vec)` than can fetch more data/trim its content based +A `DynamicData` Struc linked to a `DataLoader` than can fetch more data/trim its content based on received messages `FetchPrevious(how_many)`, `FetchNext(how_many)` / an update call. - + Solves: * Both Lazy Finite and Infinite `Scrollable` * Both Lazy Finite and Infinite anything that uses a `Vec` - * Lower computation cost in both cases: Lazyness => smaller widget lists in - scope => fewer primitives calculated and simpler/quicker layout calculations. + * Lower computation cost in both cases: Lazyness => smaller widget lists in + scope => fewer primitives calculated and simpler/quicker layout calculations. ## Motivation @@ -18,47 +18,43 @@ Solves: Solves: * Both Lazy Finite and Infinite `Scrollable` * Both Lazy Finite and Infinite anything that uses a `Vec` - * Lower computation cost in both cases: Lazyness => smaller widget lists in - scope => fewer primitives calculated and simpler/quicker layout calculations. + * Lower computation cost in both cases: Lazyness => smaller widget lists in + scope => fewer primitives calculated and simpler/quicker layout calculations. -1. In Iced, large amounts of widget lists may cause performance issues due to the -nature of update, draw, layout and view methods, even when many widgets are out +1. In Iced, large amounts of widget lists may cause performance issues due to the +nature of update, draw, layout and view methods, even when many widgets are out of view, if states change. -2. In Iced, I have not found Infinite list implementation where the +2. In Iced, I have not found Infinite list implementation where the very large/infinite list is only loaded partially when receiving requests. -Seeing as 2. usually leads to 1. I propose a `Into>` Struct that -updates (grows, trims) an inner `Vec` when requested. That `Vec` is - used as usual (transparently) by other widgets, like `Columns` and `Rows` for example - by implementing `Into>` on this wrapper (or From?). +Seeing as 2. usually leads to 1. I propose a Struct that +updates (grows, trims) an inner `data` field when requested. This `data` can +subsequently be turned into Element(s) during the view() method call of the +application. ## Detailed Explanation -A `Dynamic_Data_Wrapper(Vec)` than can fetch more data/trim its content based +A `DynamicData` Struc linked to a `DataLoader` than can fetch more data/trim its content based on received messages `FetchPrevious(how_many)`, `FetchNext(how_many)` / an update call. + Has a mutable buffer_size to let us choose how much to keep: * when at maximum capacity, `FetchPrevious(n)` pops `n` end values and inserts `n` new values at the start * when at maximum capacity, `FetchNext(n)` pops `n` start values and appends `n` new values at the end. -Implement `Into>` by returning its current contents. - Has an `OrderBy` trait that forces the Developper to define how to fetch more items (basically to now what **previous**, and **next** items are). -Systematically appends an additional "Load more" widget (stylable) at the end of the -content which can be triggered to send a message to the DDW to ask it to load more content, for -instance when GUI-interacting on it, or programmaticaly. - -Systematically inserts an additional "Load previous" widget (stylable) at the start of the -content which can be triggerd to send a message to the DDW to ask it to load more content, for -instance when GUI-interacting on it, or programmaticaly. +The `DynamicData` struct exposes methods to change its capacity, its current +position in the data, to ask the DataLoader to get more data in either direction. +Since all these methods are public, the application can simply call them for any +reason, for instance if it receives a button_pressed message.