Samuel
@samuel.fm
moving my brain dumping thread here. I think there’s two issues at play w.r.t. perf
I tried putting it behind useDeferredValue, but it didn't do anything as it seems like the scroll handler has an unstable identity for no good reason
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
1 2Easy 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
1 2I’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
1 22. 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?
2 2Each 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?
1 2There seems some randomness though. Most times opening the image is slow. I tap the image. I see the the rijple effect. Then it takes a while before the animation starts.
But sometimes the animation starts immediately after the ripple completes.