-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor to preclude the need for a continuous raf loop #1328
Conversation
🦋 Changeset detectedLatest commit: 23cd976 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
I've been running this change in production since early March |
Although I have it in production, so it's not obviously breaking things, there could be some subtleties with the shadowbuffer that might need expert analysis or a test... I wrote this based on the logic of how the weak map was cleared etc. |
a86625d
to
6cb8335
Compare
@eoghanmurray very welcome change! This was creating a lot of noise when profiling the code 👏🏼 |
@JonasBa this is a hard one for anyone to review and we don't have tests on it. |
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <[email protected]>
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <[email protected]>
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <[email protected]>
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <[email protected]>
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <[email protected]>
It seems to me that the raf loop is unnecessary, so I've removed it to get your feedback.
Instead we queue up a single raf callback which will clear anything added in this frame.
I've no understanding as to why this exclusivity is per animation frame, and not (say) per emitted mutation event, any insight into that?