fix(tracing): Guard getNewScreenTimeToDisplay behind enableTimeToInitialDisplay#5849
Merged
fix(tracing): Guard getNewScreenTimeToDisplay behind enableTimeToInitialDisplay#5849
Conversation
…ialDisplay NATIVE.getNewScreenTimeToDisplay() was called on every navigation state change regardless of whether enableTimeToInitialDisplay was enabled. This native bridge call posts to the main thread and registers a Choreographer callback (Android) or CADisplayLink (iOS) to capture the next frame timestamp. On low-end devices (Fire TV, Chromecast) this is measurable overhead that the user could not avoid even after setting enableTimeToInitialDisplay: false. The dispatch-time native calls (setActiveSpanId, navigationProcessingSpan) were already correctly guarded behind the flag. This aligns the state-change-time call with the same guard. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog.
🤖 This preview updates automatically when you update the PR. |
Contributor
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
antonis
commented
Mar 19, 2026
| } | ||
|
|
||
| addTimeToInitialDisplayFallback(latestNavigationSpan.spanContext().spanId, NATIVE.getNewScreenTimeToDisplay()); | ||
| if (enableTimeToInitialDisplay) { |
Collaborator
There was a problem hiding this comment.
Q: should we mention the performance overhead when enabling this on changelog/docs?
Contributor
Author
There was a problem hiding this comment.
I've added a note in the parameter documentation dd81064
I'll try to measure the actual performance overhead and update the doc accordingly
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📢 Type of change
📜 Description
NATIVE.getNewScreenTimeToDisplay()was called on every navigation state change regardless of theenableTimeToInitialDisplayoption. This native bridge call posts to the main thread and registers a Choreographer callback (Android) or CADisplayLink (iOS) to capture the next frame timestamp.The dispatch-time native calls (
setActiveSpanId,navigationProcessingSpan) were already correctly guarded behind theenableTimeToInitialDisplayflag. The state-change-time call was the only one missing the guard.💡 Motivation and Context
A customer reported significant performance overhead on low-end devices (Fire TV, Chromecast) even after setting
enableTimeToInitialDisplay: false. This unguarded native bridge call was still executing on every navigation, competing with the main thread on resource-constrained devices.Related issue: #5665
💚 How did you test it?
Added a new test in
reactnavigation.ttid.test.tsx:should not call getNewScreenTimeToDisplay when ttid is disabled— verifies the native bridge call is not made whenenableTimeToInitialDisplayisfalseAll 94 reactnavigation tests pass (93 existing + 1 new).
📝 Checklist
sendDefaultPIIis enabled🔮 Next steps
Part of a broader investigation into
reactNavigationIntegrationperformance on low-end devices (#5665).