Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36116
[Changelog][Internal]
Add a minimal/reference JavaScript implementation for NativePerformanceObserver - the purpose is both unit testing (JS and native sides separately) and potentially shimming the part of functionality that is not dependent on native side.
This is both a setup for adding general unit tests for the Performance* APIs, but also to be able to do non-trivial changes on JS side for WebPerformance (such as in (D43154319).
Reviewed By: rubennorte
Differential Revision: D43167392
fbshipit-source-id: 213d9534d810dece1dd464f910e92e08dbf39508
Summary:
[Changelog][Internal]
`NativePerformanceObserver` TurboModule API would get the type for performance entries as strings in one direction (`start/stopReporting`) and as integers in another direction (inside `RawPerformanceEntry`, for optimization on the native side).
This makes is symmetrical and consistent, all the conversions are now handled on the JS side.
Reviewed By: christophpurrer
Differential Revision: D43236466
fbshipit-source-id: 08e1b62df90e6d26a11577d6b6b1d91a6bce8339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35771
[Changelog][Internal]
Based on the internal discussion, we don't want to report `first-input` event types for RN (just use plain `event` instead), in the way that [Event Timing API standard suggests](https://www.w3.org/TR/event-timing), as this is doesn't have that clear semantics in the context of RN, also to keep it simpler.
Reviewed By: rubennorte
Differential Revision: D42341923
fbshipit-source-id: eff2487dee17ef082604e4c807b4d41485328114
Summary:
Extends the WebPerformance API with ability to report events, [according to the standard](https://www.w3.org/TR/event-timing/#sec-performance-event-timing).
This is an API-only change, the actual reporting comes in a separate diff, to simplify reviewing.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42097695
fbshipit-source-id: d8b468ffed50c1c3d889151df5e8ca644d6e1a68
Summary:
Prevents scenarios when internal performance buffer may grow indefinitely (e.g. due to a broken logging), communicating back to `PerformanceObserver` the corresponding amount of dropped entries, `droppedEntriesCount`, [according to the standard](https://w3c.github.io/performance-timeline/#dom-performanceobservercallbackoptions-droppedentriescount).
NOTE: The backwards compatibility check is failing, which is an orthogonal issue. I am looking into it and won't land this one before it is sorted.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008409
fbshipit-source-id: 40d30e44d39e643bfb58a6254572823cb2b3b8df
Summary:
Now that D42097191 allows it, get rid of unused API in the related WebPerformance native modules (these were kept there only to pacify the backwards compatibility checks).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42037757
fbshipit-source-id: 5f5e7e76722cade9e730aba037f9e8ab51fc16d9
Summary:
Makes sure that we don't spam too often the JS performance entry reporting callback, which further dispatches entries to `PerformanceObserver` instances.
The logic is as following:
* ~~~If internal buffer of entries reaches the limit, we schedule the callback (with background priority)~~~
*~~~ Once the callback is processed, we schedule the next flush after a timeout of 500ms, this will also be scheduled from native with background priority~~~
* ~~~Whenever new performance type starts to be observed, we also schedule the callback, in order to prime the above~~~
* Schedule the flush with low priority, whenever there is the first entry coming into an empty buffer, and rely on the Scheduler to "do the right thing" when asked to flush it with background priority and not doo it exceedingly often (see the prolonged discussion)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D41875085
fbshipit-source-id: 368b525203215350ceabb43d5e9e8e3bd5242aca
Summary:
Changelog: [Internal]
This adds JS side implementation (including the API) for the `Performance.measure` functionality, [as described in the corresponding standard](https://www.w3.org/TR/user-timing/#measure-method).
The JS part is separated from the C++ implementation (further down the stack) to help the review being more focused.
Reviewed By: mdvacca
Differential Revision: D41733190
fbshipit-source-id: 72b69f6bb332aed4b9477a186b0e818b62009220
Summary:
[Changelog][Internal]
The NativePerformance module functionality corresponds to the [timing extensions of the Performance API standard interface](https://www.w3.org/TR/user-timing/#extensions-performance-interface).
As this is logically separate from `PerformanceObserver` (which may exist without it), it makes sense to have it as a different native module, so there is no coupling between both.
Reviewed By: christophpurrer
Differential Revision: D41690145
fbshipit-source-id: 7443f4c51f54cc2fdddbdb2e89f9a1fa457ab280
Summary:
[Changelog][Internal]
The name corresponds more precisely to what the method does.
Reviewed By: christophpurrer
Differential Revision: D41686205
fbshipit-source-id: 36c47b57fdeb757515cd14b890f38247f7fe8d02
Summary:
[Changelog][Internal]
Adds API definition for [Performance.mark](https://www.w3.org/TR/user-timing/#mark-method) support.
This is a bare bone implementation, that just logs events on the native side. The next step is the native logic for queuing, flushing etc.
Note that here I route both JS and native marks to native for now, for simplicity sake - ultimately this may not be what we want, as it may be more efficient to process marks, logged from JS, on the JS side.
Reviewed By: rubennorte
Differential Revision: D41472148
fbshipit-source-id: bdf2b182b8472a71a5500235849bca5af1c2f360
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35226
Changelog: [Internal]
This adds scaffolding for the C++ side of NativePerformanceObserver module.
Thanks to christophpurrer for helping set this up, as this is the first one of this kind inside core/OSS.
Reviewed By: rubennorte
Differential Revision: D41028555
fbshipit-source-id: 4acf0e71a254a42044cbbe5f94f40938342c6aa2
Ruslan Shestopalyuk
Christoph Purrer