rfcs
rfcs copied to clipboard
Lazy Finite or Infinite data in Widgets
A proposition to allow for lazy finite or infinite data in Widgets as a Wrapper that is indistinguishable from a Vec<Widget>
.
I believe it would help with:
- Both Lazy Finite and Infinite
Scrollable
- Both Lazy Finite and Infinite anything that uses a
Vec<Widget>
- Lower computation cost in both cases: Lazyness => smaller widget lists in scope => simpler updates, fewer primitives calculated, simpler/quicker layout calculations.
I have started a POC on this and realised wrapping widgets would not work (Vec<Widget>
, it is the data that needs to be wrapped.
My POC is complete and works well, I will share it asap.
Yes, I sometimes get tripped on that too. Component vs Elm Architecture mentality.
I could definitely use this in my own implementation of a sort of an image gallery. I'll link to my demo once I get some subscription stream concurrency bugs for thumbnailing process addressed.
I'd really like to see what you have so I can use it in mine.
Here it is : https://github.com/GTimothy/iced_pocs/commit/c5cbb41c16e7cee824133d3c24387f7034fe72fa No readme.md yet but the example is quite short so I hope it is understandable.
Made a small simplification of the code in https://github.com/GTimothy/iced_pocs/commit/7112d03c802f92b7682d82925d6f87056a61a954
I checked out your project, @GTimothy , and it looks interesting.
I'm not sure it does exactly as I was expecting it to, but you're working with text. The optimizer in me wants to think of a way to apply Lazy scroll to my image gallery code, which you can find (finally finished) here:
https://github.com/FuzzrNet/Fuzzr/pull/92
However, I'm not sure it's worthwhile. I save a CPU power by not re-encoding thumbnails, and I have really good streaming parallelization for thumbnailing, so it might be challenging to get that to work on top of a lazy scroll. What's more, is that even with a thousand images, it still performs quite well! Iced is incredibly fast.
As such, this feature will probably have limited utility beyond very large data sets, such as ones that are held on a server. However, I may revisit this perspective once people start actually using my project!