Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.
I guess that egui works similar to Dear ImGui: only (font) texture changes and clip regions (e.g. scroll areas) require a new draw call, and that's typically just a handful to a few dozen draw calls even for complex UIs.
For long lists, Dear ImGui has a special 'ListClipper' class which allows to iterate over the visible 'slots' of a list, so that the code which describes the list UI can skip clipped items early. Not sure if egui has something similar.
An egui ScrollArea can request only visible rows from a callback using show_rows:
https://docs.rs/egui/latest/egui/containers/scroll_area/stru...