3 ms·

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table o

by jb1991 4y ago

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the battery as your device will doing orders of magnitude more work than necessary. You don't encounter lists of this length as often on web apps, but the same issue would apply if you did -- why do you think infinite scrolling only loads a few rows at a time until you scroll further? And how many times have you been on an "infinite scroll" web and as you scrolled, you had to wait for it to do the work for the next scrollable content. Happens to me often. Now take all those concerns and bundle them in a UI that is suppose to manage all this for you automatically via declarative behavior, and you can see why it's not as trivial as you suggest.

WA 4y ago
Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.
- jb1991 4y ago
  Well at least what you describe would be sitting on a GPU using all the technologies (both hardware and software) developed for precisely that purpose. Also keep in mind that the battery drain using those technologies to play a game does not scale to a normal mobile app when people expect their phone to be available all day.
- avianlyric 4y ago
  Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of course, stutter and jump if they need to dynamically load new content in, but can’t quite get it into working memory before it’s needed for rendering, usually resulting in entire frames being delayed. Scrolling on the other hand is a very sequential task, if you don’t want to have a loading screen before displaying the list. The location of every item in the list depends on the location and size of the item before it, those data dependencies make parallelism pretty close to impossible. Made worse when each item is loaded on demand, and needs to execute code to determine how it should be rendered. Of course, you could load all your scroll data into memory, precompute all the needed render parameters, arrange the results for parallel rendering, then have blazing fast and stable scrolling. Just like a video game loading screen, but then every scrollable view would have a loading screen…
  - sicp-enjoyer 4y ago
    Filling polygons has never been the hard part of realtime games. It's all the work that gets you to be able to fill just the polygons you need in the way you want them. It is not a big ask to have a scrolling UI. Look at motif from 80s.
kitsunesoba 4y ago
Infinite scroll on web also rarely recycles elements. It’s more common for sites to leave elements sitting in the page with memory usage gradually creeping up as you scroll. They largely depend on you not scrolling far enough for that to become a problem.
sicp-enjoyer 4y ago
Are you suggesting that the programmer should be able to pass a tree of 10,000+ heterogeneous nodes with transformation and styling and it just works without them thinking about how to break up that problem? It is a solved problem, the solution is load things lazily as needed, and the UITableViewDataSource protocol is one template you can follow for doing that.
- jb1991 4y ago
  iOS UITableViews are what I was referring to: > using UIKit...you use an api that recycles UI components to support lazy loading
  - sicp-enjoyer 4y ago
    Maybe I misunderstood. Weren't you expressing that this was a poor or convoluted solution to scrolling?

by jb1991 4y ago

WA 4y ago

Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.

jb1991 4y ago
Well at least what you describe would be sitting on a GPU using all the technologies (both hardware and software) developed for precisely that purpose. Also keep in mind that the battery drain using those technologies to play a game does not scale to a normal mobile app when people expect their phone to be available all day.
avianlyric 4y ago
Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of course, stutter and jump if they need to dynamically load new content in, but can’t quite get it into working memory before it’s needed for rendering, usually resulting in entire frames being delayed. Scrolling on the other hand is a very sequential task, if you don’t want to have a loading screen before displaying the list. The location of every item in the list depends on the location and size of the item before it, those data dependencies make parallelism pretty close to impossible. Made worse when each item is loaded on demand, and needs to execute code to determine how it should be rendered. Of course, you could load all your scroll data into memory, precompute all the needed render parameters, arrange the results for parallel rendering, then have blazing fast and stable scrolling. Just like a video game loading screen, but then every scrollable view would have a loading screen…
- sicp-enjoyer 4y ago
  Filling polygons has never been the hard part of realtime games. It's all the work that gets you to be able to fill just the polygons you need in the way you want them. It is not a big ask to have a scrolling UI. Look at motif from 80s.

kitsunesoba 4y ago

Infinite scroll on web also rarely recycles elements. It’s more common for sites to leave elements sitting in the page with memory usage gradually creeping up as you scroll. They largely depend on you not scrolling far enough for that to become a problem.

sicp-enjoyer 4y ago

Are you suggesting that the programmer should be able to pass a tree of 10,000+ heterogeneous nodes with transformation and styling and it just works without them thinking about how to break up that problem? It is a solved problem, the solution is load things lazily as needed, and the UITableViewDataSource protocol is one template you can follow for doing that.

jb1991 4y ago
iOS UITableViews are what I was referring to: > using UIKit...you use an api that recycles UI components to support lazy loading
- sicp-enjoyer 4y ago
  Maybe I misunderstood. Weren't you expressing that this was a poor or convoluted solution to scrolling?