the scholar claudes *must* believe themselves to be wearing long scholarly robes, and speak in a dreary tone

moving my brain dumping thread here. I think there’s two issues at play w.r.t. perf

1. List component rerendering. we need to change a scrollview prop on iOS. I already scoped this to iOS-only, so it’s not a perf concern on Android, but it’s got a massive over-render problem. changing this one tiny prop causes every list item to rerender, which is ridiculous

Easy solution - take my existing useScrollsToTop hook, and put a useDeferredValue on it. therefore we can defer this nonsense until after the lightbox has finished rendering alas no. List rerender anyway. Profiler blames onScroll, and I added logging and yeah it changes on that initial ctx change

I’m pretty sure it’s just unstable, I.e. different identity on each render, which shouldn’t be the case - it’s not doing anything here! next step is to narrow down what’s causing it to change. Reanimated has some magical auto-dep-array stuff which is probably to blame - likely doesn’t mesh w/ RC

2. Slow on Android Perf on Android is still unacceptable, especially for 2+ images. I have yet to dig in but I have speculation. the animation gets triggered in a requestAnimationFrame. I’m guessing the main thread is getting locked up so it has to wait a really long time?

Each time each image in the lightbox loads, it re-renders with its image dimensions. So we have 4 fairly heavy components (each image) rendering invisibly before the animation can begin, and each one re-renders as they load. maybe the animation is queued behind that whole process?