RESOLVED INVALID 121833
Not accurate behavior of the requestAnimationFrame API
https://bugs.webkit.org/show_bug.cgi?id=121833
Summary Not accurate behavior of the requestAnimationFrame API
quho
Reported 2013-09-24 04:00:23 PDT
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
Attachments
the test case (888 bytes, text/html)
2013-09-25 18:31 PDT, quho
no flags
quho
Comment 1 2013-09-25 18:31:36 PDT
Created attachment 212649 [details] the test case
zalan
Comment 2 2013-09-26 07:47:07 PDT
(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
Comment 3 2013-10-17 02:40:12 PDT
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
Note You need to log in before you can comment on or make changes to this bug.