Touchable: layout is measured during touch-scroll event

[hushicai]

The problem

As mentioned in #1157, Touchable _remeasureMetricsOnActivation was called when we touch to scroll, and cause browser Layout due to the getRect:

I have find out that it is called on native too.

But there is no performance problem in native.

Browser Layout costs so much times, making the scroll performance so bad!

How to reproduce

A large List, with Touchable items, can reproduce the problem.

<ScrollView>
   // the more complicated of the TouchableOpacity view tree, the easier to reproduce.
  <TouchableOpacity style={styles.item}></TouchableOpacity>
  // ...
  // ...
  // ...
</ScrollView>

const styles = StyleSheet.create({
  // The bigger the visual rect, the easier to reproduce.
  item: {width: '100%', height: 100} 
});

Expected behavior

Hope to look for a solution, and improve the scroll performance.

[hushicai]

Find a very amazing thing！

Look at the red box in the above image!

I try to remove the setOpacityTo call in TouchableOpacity:

And everything become ok!

I don't known why, but i find that opacity can also cause Layout in webkit from css triggers.

As we can see, maybe this is the main reason of the poor scroll performance in IOS safari.

Amazing, it is really out of my mind!

[hushicai]

I profiled on mac chrome, no Layout at all when setOpacityTo:

[hushicai]

Use TouchableWithoutFeedback instead of TouchableOpacity in my large FlatList, solved the peformance problem.

And there is not Layout performance now:

[hushicai]

Maybe settting opactiy and getRect in the meantime cause this problem?

I think the key point maybe, "update opacity style before getRect in a frame", and then cause the Force Sync Layout.

[necolas]

Interesting! Thanks for investigating. How does TouchableHighlight look? I wonder if using will-change:opacity helps the browser to optimize this path and avoid triggering layout on other elements

[hushicai]

TouchableHighlight is better than TouchableOpacity

This is because TouchableHighlight has a highlight delay in HIGHLIGHT_DELAY_MS .

If scroll event happened in HIGHLIGHT_DELAY_MS, Touchable will terminated by ScrollView, and not highlight call; but If I stay on the Touchable for more than HIGHLIGHT_DELAY_MS, and then scroll again, highlight will also suck the scroll performance, as shown in the above picture.

TouchableOpacity is different:

It will be highlighted immediately when i touch to scroll!

Should TouchableOpacity delay highlight too?

[necolas]

The touchables are going to change in RN. If there's nothing we can do for web (rAF, will-change, etc) then I'll bring the issue of performing layout measurement during scroll with the team. I think it's probably good to avoid that situation in general. Thanks again for continuing to look into layout perf 😍

[hushicai]

will-change is useless, maybe useful for repaint.

It will lift up lots of Compositing Layers, which increase memory:

I suggest to delay highlight with TouchableOpacity for now, it is very useful for quick scrolling in large FlatList.

[necolas]

If it's about the opacity, transitioning to 0.99 instead of 1.0 used to be a hack to avoid browsers doing extra work.

Changing the delay will make it inconsistent with RN and doesn't fix cases where people are setting their own short delays