2

Suppose I make changes to an element inside a frame created with window.requestAnimationFrame and that the modified element is being observed by a MutationObserver. Does the MutationOberserver's change handler fire within the same frame and before the browser does rendering that comes after the frame?

(I can imagine that this may not be true with some polyfills. I'm curious to know if there's any guarantee that this is true in native implementations.)

EDIT: A possibly better question is Are microtasks guaranteed to fire within the same animation frame where they were queued?, which may indirectly answer this question, as well as explain Promise behavior, or behavior of anything else that uses microtasks.

EDIT July 19 '17: The reason I want to know about this, is because I want to know exactly how modifying DOM and doing custom rendering (f.e. WebGL) based on the DOM mutations can be kept in sync with the browser's paint.

For example, suppose a user of my custom elements uses requestAnimationFrame, then modifies some attribute of my webgl-purposed custom elements. I would like to be able to guarantee that I can react to those changes before the browser paint that will follow after the animation frame, do my webgl render stuff that the user will be expecting, and have it show up in the next frame, not any later frame.

Based on some theory, I am aware that Promise microtasks fire after the current macrotask, and based on some testing I've done, I have verified that Promise handlers defined in an animation frame will fire before the next browser paint.

Extending this to Mutation Observers, I believe that they fire in the next microtask, and therefore they will behave the same as Promise handlers: firing before the next paint.

I think I've answered my question, but maybe confirmation would be of benefit.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
trusktr
  • 44,284
  • 53
  • 191
  • 263
  • `MutationObserver` is asynchonous. The change will be reported on a future tick of the clock. –  Nov 16 '16 at 04:59
  • @torazaburo I knew that, but that doesn't mean it's not possible for it to fire within the same animation frame. For example, `Promise`s can be fullfilled on future *micro*ticks within the same animation frame at some point in the future but before the frame is over (I verified this behavior in Chrome here: https://mail.mozilla.org/pipermail/es-discuss/2016-April/045905.html) – trusktr Nov 16 '16 at 05:18
  • did you read [this article](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/)? – Max Koretskyi Jun 14 '17 at 17:39
  • @Maximus Yes I did, and I also read the specs on MutationObserver and requestAnimationFrame, and it is still not clear. – trusktr Jun 17 '17 at 05:19
  • 1
    @trusktr, from what I've read, MutationObserver handlers are scheduled as microtask, so they should be executed before a browser rerenders - in the same animation frame – Max Koretskyi Jun 17 '17 at 07:21
  • @Maximus I think this makes sense. I would guess this is the case too. Gotta test it somehow. It would mean the MutationObserver callback would fire along with promise settlement handlers, after the animation frame's macro task. – trusktr Jul 19 '17 at 22:35

0 Answers0