Feature request: virtual scroll

[hyperstown]

Hi, I've been using this gallery for a quite some time now and over the years one limitation has become painfully clear: Gallery can't handle more that 1000-2000 images depending on device. While this seems like a lot it's really not. Just a few years of holiday photos, memes and other random photos can easy surpass 5k mark. So far my solution was to load 500 items per page and reload gallery every page but it's inconvenient for scrolling through tens of thousands of images. Another issue is that even with 400 images loaded resizing display (like rotating the phone) causes significant lag. The issue is that every loaded images stays on DOM forever. After a bit of research I discovered that virtual scroll would just solve all of those issues. React gallery masonic handles ridiculous amount of data with basically no lag. It's extremely fast even on low end devices.

While this is a feature request I did some PoC with codex that perhaps could be used as a template. It's available here . I've decided to NOT create PR since this code was mostly generated with AI and due to my limited time I was not able to fully review it. I've been testing it however for a last few days and it works really well. In my experience AI is good for laying out concepts that a person with full knowledge of codebase and much experience can turn into excellent patch.

If anything like that could be added it would be much appreciated.

[sambaptista]

Hi, thanks for your feedback and idea.

For sure the gallery does not deal with virtual scroll and it could be a nice addition. I'll have a look on your fork as soon as I have a moment.

Actually all usages we've witnessed lead to establish a common behavior when dealing with bit amount of images : use filters / navigation to limit the collection. When people wants to reach 400th item, they prefer to focus on a search rather than scroll.

I'm curious, how do you use your gallery to reach hundreds of images loaded on the DOM ? do you scroll for 10 minutes manually ? Don't you load them all progammatically do you ?

[hyperstown]

I use this library mainly for two things actually:

1. A gallery for my central photos storage. Photos taken from the can't really be searched without involving ML. I know that there are other solutions but in this particular case my setup works best.
2. Image aggregator from various image boards. Something like RSS for memes, art and stuff. Rarely I get scroll past 1000 results but when I do things start to get slow.

In both setups I display 2-6 images per row depending on image size and display dimensions. In case of gallery I scroll until I done sorting stuff out. Could be a few minutes and thousands of images. Images load dynamically, paginated by date 100 per page. Image aggregator depending on selected source can be like 10 images per day to almost endless, depending on selected API it loads 20-100 images per page.

[sambaptista]

Pushed on master, but not released, neither deeply tested yet. Can you test and provide feedback with your massive dataset and phone flipping ?

You can clone, run pnpm build and use dist content.

[hyperstown]

Thanks for so quick implementation!
I did some testing and:

• scrolling performance is good, I'll do more detailed analysis in the future since for now I'm only saying this based on the feel and memory usage.
• resizing/rotating both masonry and natural is significantly slower than masonic or in PoC. On PC I couldn't say for sure but on lower-end phone it's very noticeable. Resizing window also scrolls to the top in Masonry mode. In both modes it changes position of the scroll. So resizing from 400px to 1000px and then back to 400px produces different images being displayed. The easiest way to confirm that is by rotating the phone. Each phone rotation will change scroll position resulting different images being in view. In masonry mode I also found that after scrolling 500 images or so and rotating the phone server got crushed with requests, masonry started requesting ridicules amount of images. Memory seemed fine so I'm guessing scroll position forced loading another 500 images since rotating phone meant twice the amount of images are displayed per screen height.
• I also noticed that sometimes one images get loaded and immediately gets replaced with other. Again something that happens only on lower end device.
• Programmatic scroll doesn't work (eg scroll to top galleryWrapper.scrollTo({ top: 0, behavior: "smooth" });. I couldn't figure it out in my PoC so I did dedicated function for scrolling since this was the quickest working solution.

I'll try doing some more testing and stress testing when I'll get a chance.
I hope it helps.

[sambaptista]

Yes very helpfull.

I pushed optimisations, performance + behavior. Can you re-test please ?

[hyperstown]

Hello, I'm really sorry for the late response, last month has been extremely busy for me and I just didn't have any time to spare for proper testing.
But now I'm back and to make up for this delay I throw together a nice (I think) testing page where we can compare my first attempt at virtual scroll, with current upstream. (I can't vouch for the quality of the code of this attempt but I've been using it for some time and it works good for me)
As a bonus I also threw masonic that although only does masonry layout and it also only works with react it still has the best performance when scrolling and resizing among all virtual scrollers.
At first I was thinking about just open sourcing my gallery but the code I made many years ago is definitively something that should not be out in the internet. On top of that I wasn't sure if some of the issues didn't came from from my spaghetti code rather than the gallery itself.
Testing grounds are on my github pages: https://hyperstown.github.io/gallery/demos/ and the source code for all demos is in this repo: https://github.com/hyperstown/natural-gallery-js-demos if you want to check it.
I'm glad I decided to do a clean rewrite because issues with smooth scrolling on rotate disappeared. As for things I discovered with my testing:

• Resize is still taking considerable amount of time to re-render. It gets worse with items count. As for numbers with only 600 images it's more of less something like this:

	layouts	layout time	recalc time	script
upstream	236	205.8 ms	133.7 ms	25.7 ms
my attempt	14	3.2 ms	18.4 ms	9.3 ms

Just throwing this to show that it's noticeable even with less than 1000 items.

I checked the code and if I understand correctly endResize() method inserts all items with restoreAllTopItems() and restoreAllBottomItems()? If that's the case then it should be possible to re-organise from collection data without re-attaching, then trim to the window in one step. The DOM only ever needs the visible rows, even mid-resize.

• Moving scroll position in one go (For example keyboard home/end buttons) can leave all DOM elements rendered. This is something that it's easy to reproduce in dev console:

var scrollRef = $('main')
// scroll normally, load 400 photos or so
scrollRef.scrollHeight // 46439
$$('figure').length // 20 - ok
// click 'back to top' btn
$$('figure').length // 12 - ok
scrollRef.scrollTop = 32439 // some value like idk 70-80% height
$$('figure').length // 222 - all loaded, huge CPU spike.

• This is not really a bug but more of a inconvenience. It's kinda hard to describe but continuous adding of items makes it harder to jump ahead.
  Basically something like this:

  • upstream: 1 628 → 4 605 → 7 432 → 10 058 → 12 805 → 15 193 (grows continuously)
  • my attempt: 15 246 → 15 246 → 31 472 → 31 472 → 47 686 (steps only when a page loads)
    That means the scrollbar thumb never settles, you cannot drag into content you have not
    walked to. Row heights are deterministic once the width and the ratios are known, so the
    height of everything loaded can be known upfront.

• Also something that possibly might improve performance: Currently _domCollection keeps rootElement with all the events and never release it. Removing and adding rootElements seems like something that can improve memory footprint. Also since we have both collection and domCollection we could dynamically drop stuff from domCollection? After all it no longer stores what it says it does. With 20 real dom elements domCollection can have 200 or 2000.

[sambaptista]

I've been busy, I'm going at it soon.

I know actual version is buggy that's why it's not released, I have to dig your message too.