Bug 121833 – Not accurate behavior of the requestAnimationFrame API

• Component: Layout and Rendering
• Status: RESOLVED INVALID

[quho]

While I testing the requestAnimationFrame API. I found small crack on there.

When one changes the contents at the requestAnimatoinFrame callback, it should be displayed, even though there is additional change between the two consecutive requestAnimationFrame callbacks.

So I write the attached test code, which is change the <p> tags contents into "text from requestAnimationFrame" on requestAnimation frame, and after that, within short time I've changed it into "text from setTimeout". In theory, it should display the "text from requestAnimationFrame for all time. But it's flickering or just display the "text from setTimout" always.

Is it a correct behavior? Or did I misunderstand something?


Attached r.html is the test code.

Thanks,
Quho

[quho]

Created attachment 212649 [details]
the test case

[alan]

(In reply to comment #0)
> While I testing the requestAnimationFrame API. I found small crack on there.
> 
> When one changes the contents at the requestAnimatoinFrame callback, it should be displayed, even though there is additional change between the two consecutive requestAnimationFrame callbacks.
> 
> So I write the attached test code, which is change the <p> tags contents into "text from requestAnimationFrame" on requestAnimation frame, and after that, within short time I've changed it into "text from setTimeout". In theory, it should display the "text from requestAnimationFrame for all time. But it's flickering or just display the "text from setTimout" always.
> 
> Is it a correct behavior? Or did I misunderstand something?
> 
> 
> Attached r.html is the test code.
> 
> Thanks,
> Quho

requestAnimationFrame() gets called before the browser performs the next repaint. However it is not defined when the repaint actually happens. It seems like you expect to have it happen soon after your JS function returns, but it's neither defined nor guaranteed. It could very well happen sometime after your timer hits.
Firefox behaves the same.

[quho]

True, very true.
I agree that current behaviour is meet with the specification.

But, I'm saying in terms of efficiency. 
The remaining, additional painting is useless operations. So we can remove it if it's possible.

Thanks,
Quho