Alleviate excessive layout jittering when resizing window

[tido64]

• I am removing an existing difference between facebook/react-native and microsoft/react-native-macos 👍
• I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos 👍
• I am making a fix / change for the macOS implementation of react-native
• I am making a change required for Microsoft usage of react-native

Summary

Resize events overwhelm RN, causing seemingly infinite jittering when the window is resized. By throttling layout, we can help RN catch up. Resolves #322.

Changelog

[macOS] [Fixed] - Alleviate excessive layout jittering when resizing window

Test Plan

Microsoft Reviewers: Open in CodeFlow

[anandrajeswaran]

A 0.25s delay in layout is usually deeply perceptible. We should not sacrifice that in the layout of simple scenarios and should instead look for the actual inefficiencies in layout when we have a scrollview

[tido64]

From investigating issue #322, the cause of the jittering comes from calling updateAvailableSize which queues work on the UI manager queue. Unless we can optimize away the thread jump, I'd argue this is still a lot better than the current behaviour:

[TheSavior]

Is resizing done purely in native? Or is resizing the window causing events into JS like onLayout that is triggering additional re-renders that jitter? If the issue is some back and forth between native and JS, perhaps we would want to throttle the events to JS on resizing but let everything on the native side happen live?

[tom-un]

I tried throttling the number of onLayout events fired in RCTUIManager.m and even with intervals of seconds the layout jitter still occurs.

I found, as @tido64 discovered, the excessive thread hops from native to JS is during the barrage of calls on main thread by UIKit to [RCTRootContentView layoutSubview] -> [RCTRootContentView updateAvailableSize] -> [RCTUIManager setAvailableSize:] -> [RCTUIManager _executeBlockWithShadowView:]. The final call queues blocks to the JS thread. Perhaps a coalescing of these thread hops: only queue the latest update after an interval.

[tido64]

Perhaps a coalescing of these thread hops: only queue the latest update after an interval.

I did try this initially but ran into an issue with RN layout randomly not being updated properly if resized quickly:

Where we throttle now in the current iteration does not exhibit this behaviour.

[tom-un]

I tried throttling just the calls across the bridge in [RCTRootContentView updateAvailableSize]. At first I thought I looked very promising but then I would hit cases occasionally where, as you describe above, the final layout would look as if it missed a frame. I could not figure why. Just for the record, this is what I changed in updateAvailableSize:

- (void)updateAvailableSize
{
  if (!self.reactTag || !_bridge.isValid) {
    return;
  }

#if !TARGET_OS_OSX // [TODO(macOS ISS#2323203)
  [_bridge.uiManager setAvailableSize:self.availableSize forRootView:self];
#else
  CGSize availableSize = [self availableSize];
  if (!_throttleUpdateAvailableSize) {
    NSTimeInterval interval = [[NSDate date] timeIntervalSinceDate:_lastUpdateAvailableSize];
    if (interval >= RCT_UPDATE_AVAILABLE_SIZE_THROTTLE) {
      _lastUpdateAvailableSize = [NSDate new];
      NSLog(@"*** non-deferred update");
      [_bridge.uiManager setAvailableSize:availableSize forRootView:self];
    } else {
      _throttleUpdateAvailableSize = YES;
      __weak typeof(self) weakSelf = self;
      dispatch_after(dispatch_time(DISPATCH_TIME_NOW, RCT_UPDATE_AVAILABLE_SIZE_THROTTLE * NSEC_PER_SEC), dispatch_get_main_queue(), ^{
        typeof(self) strongSelf = weakSelf;
        if (strongSelf != nil) {
          strongSelf->_throttleUpdateAvailableSize = NO;
          CGSize currentAvailableSize = [strongSelf availableSize];
          if (!CGSizeEqualToSize(currentAvailableSize, strongSelf->_lastAvailableSize)) {
            NSLog(@"**** Should not happen ****");
          }
          NSLog(@"*** deferred update");
          [self->_bridge.uiManager setAvailableSize:strongSelf->_lastAvailableSize forRootView:strongSelf];
        }
      });
    }
  }
  _lastAvailableSize = availableSize;
#endif // ]TODO(macOS ISS#2323203)
}

Then I tried scoping your solution here to just impact RCTRootView.m: moved the layout override from RCTUIView to RCTRootView. It works, it doesn't skip any layout steps, but it feels like a safer, more scoped change than doing the workaround to all the RCTViews. I propose we go with this scoped fix for now and revisit the layout when Fabric is enabled for macOS.

[tido64]

Thanks, @tom-un. I've moved the throttling to RCTRootView as suggested.

[tido64]

@anandrajeswaran: Can you please take another look? I think this is as good as we can get it with the current limitations.

[anandrajeswaran]

@tido64 I'm still a bit nervous about it because it seems like it impacts all cases while the problem only manifests when a scrollview is in the hierarchy? But if the consensus is that this behavior feels that much better for a relatively common case and should be easy to undo as we get to fabric then it seems reasonable to go ahead with it

[TheSavior]

On web I think it would be expected to throttle resize events vs all layout events. Is that something we are able to intercept and throttle in macOS?

[anandrajeswaran]

On web I think it would be expected to throttle resize events vs all layout events. Is that something we are able to intercept and throttle in macOS?

@TheSavior the system automatically does that for you using WindowServer. The application resizing slowly doesn't block the user interaction, but the quicker it can layout the quicker the user can see what layout at the new size would look like. You can see that in the video in this PR - the window background resizes smoothly but it's just the contents that flicker because layout in the canvas lags so far behind and the system is heavily throttling us.