[RN + Reanimated 3] Drag-to-scroll causes unavoidable chop/jitter — block is child of ScrollView

[Lovro31986]

I have a 24-hour vertical timeline where activity blocks are absolutely positioned inside an Animated.ScrollView. When dragging a block to the screen edge, a JS-thread motor auto-scrolls the view while a useDerivedValue compensates the block position to keep it under the finger.

The result is persistent chop/jitter that gets worse the faster the scroll speed is. Multiple AI models have failed to fix this over many hours.

---

Current architecture:

The motor drives auto-scroll on the JS thread:

autoScrollTimer.current = setInterval(() => {
  if (motorSpeed.value === 0) return;
  const currentY = virtualScrollY.value;
  const nextY = Math.max(0, Math.min(currentY + motorSpeed.value, MAX_SCROLL));
  if (nextY !== currentY) {
    virtualScrollY.value = nextY;
    scrollRef.current?.scrollTo({ y: nextY, animated: false });
  }
}, 16);

The block position is computed via useDerivedValue:

const liveTop = useDerivedValue(() => {
  if (isFloating.value) {
    const rawTop = originalTop.value + absoluteTranslationY.value + (virtualScrollY.value - initialScrollY.value);
    return Math.max(10, Math.min(rawTop, DAY_END_BOUNDARY - blockHeight));
  }
  return blockMatrix.value[i]?.top ?? topPos;
});

And applied via useAnimatedStyle:

const animatedStyles = useAnimatedStyle(() => ({
  top: liveTop.value,
  height: isFloating.value ? blockHeight : blockMatrix.value[i]?.height,
  transform: isFloating.value ? [{ scale: 1.02 }] : [{ scale: 1 }]
}));

---

Root cause (as best I understand it):

The block is a child of the ScrollView. When the native scroll moves, the OS repositions all children at the GPU level. The JS-thread motor then writes a compensating top value — but these two updates hit the GPU at different times, causing a visible oscillation that gets worse at higher scroll speeds.

---

What I've tried:

• setInterval → not frame-synchronized, causes phase drift
• requestAnimationFrame → same problem
• useFrameCallback writing virtualScrollY + useAnimatedReaction calling scrollTo → causes Android ANR or freeze+teleport
• transform: translateY instead of top to cancel scroll movement → same chop, plus boundary issues at 00:00 and 24:00
• Using scrollY from scroll handler instead of virtualScrollY → one frame behind, still chops

---

What I think the real fix requires:

1. Portal the block outside the ScrollView during drag so native scroll stops affecting its coordinate space, OR
2. Some native-driver interception I'm not aware of

Questions:

1. Has anyone successfully implemented smooth drag-to-scroll with absolutely positioned items inside a ScrollView in Reanimated 3?
2. Is there a way to detach a child from ScrollView coordinate space during a gesture without a full portal?
3. Is there a known pattern for compensating scroll movement on the UI thread (not JS thread) so the compensation and the scroll happen in the same frame?

Versions: RN 0.73+, Reanimated 3.x, Gesture Handler 2.x, Android

Happy to share full code.

[MatiPl01]

Hey @Lovro31986!

In general, it is hard to get scrolling perfectly synchronized with gesture-based position updates of the view. The correct approach is to react to the ScrollView position changes on the UI thread (e.g. with the useScrollViewOffset hook or by using the useAnimatedScrollHandler. You should also update the position of the ScrollView on the UI thread, not from the JS thread as you do. To do this, you can call the Reanimated's scrollTo function (it must be called from the UI thread, so in the useAnimatedReaction, useDerivedValue, useFrameCallback or other Reanimated hook's callback).

---

useFrameCallback writing virtualScrollY + useAnimatedReaction calling scrollTo → causes Android ANR or freeze+teleport

Did you call runOnJS with the JS scrollTo implementation or used the Reanimated's scrollTo version? I am aware of this problem on the New Architecture - do you use the Old Architecture or the New Architecture in your project? The scrollTo function, even the one from Reanimated, can crash if is called too often (e.g. on each animation frame) as it uses a different implementation than on the Old Architecture, which is slower but we had to change it to fix some other issues with scrolling. The correct solution here is to debounce the scrollTo calls and call it less frequently with animation to keep scrolling smooth.

What I think the real fix requires:
Portal the block outside the ScrollView during drag so native scroll stops affecting its coordinate space, OR

This can fix the jittering problem but won't fix the scrolling freeze issue caused by calling scrollTo too often. You will still have to debounce scrollTo calls to limit the frequency.

Questions:
Has anyone successfully implemented smooth drag-to-scroll with absolutely positioned items inside a ScrollView in Reanimated 3?

Have you seen the react-native-sortables library? I wrote it some time ago as I struggled with similar issues as yours. Here is an example showing how to use the auto scroll feature. You can create a 1-column grid to achieve what you want. One think to keep in mind, this library doesn't support virtualization so if you render a few items, it is fine, but rendering tens or hundreds of items will hurt performance. You may also try a portal feature which may make the item movement smoother. Let me know if you have any questions.

[Lovro31986]

Thank you so much for the detailed response! This perfectly validates what I was experiencing. I am indeed running the New Architecture, and the scrollTo bottleneck crashing/teleporting when called via useFrameCallback or high-frequency useAnimatedReaction was exactly the wall I hit.

I looked into react-native-sortables (awesome library, by the way!), but my use case is a strict 24-hour timeline where items have absolute positions based on exact time metrics (1 pixel = X minutes), and items can be resized/overlapped.

Since throttling scrollTo with animated: true handed speed control over to the OS (which flung the view way too fast), I ended up building a "GPU Canvas Illusion" to bypass the scrollTo bottleneck entirely. Here is how I solved it:

Lock Native Scroll: On gesture start, I lock the Animated.ScrollView (scrollEnabled={false}) so the native offset is completely frozen.

The GPU Canvas: I wrapped the inner grid content in an Animated.View. When the finger hits the top/bottom 120px edge zones, I trigger a withTiming animation on a canvasOffset shared value to translateY the wrapper. This gives me perfect, buttery 120Hz scrolling at the exact speed I want, without firing a single scrollTo command.

The Portal: The dragged item is portaled absolutely outside the scroll view. Its visual position is calculated purely on the UI thread: absoluteY + frozenScrollY + canvasOffset.value.

The Handoff: On .onEnd, I calculate the final virtual position, fire a single scrollTo(ref, 0, finalY, false) to snap the real ScrollView into place, and instantly reset canvasOffset.value = 0 in the same frame. The swap is visually seamless.

It took a bit of surgical math to clamp the withTiming target so it doesn't overshoot the ScrollView's true content size, but it completely sidestepped the Fabric scrollTo limits. Thanks again for confirming that limitation—it kept me from going crazy trying to debug the C++ bridge!

[MatiPl01]

Thanks for the detailed explanation. If you used reanimated v4, I would suggest enabling the DISABLE_COMMIT_PAUSING_MECHANISM feature flag and checking if it fixes the issue but you are reanimated v3 so there is no better simple solution that I can suggest.