[Webkit-unassigned] [Bug 66280] [GTK] requestAnimationFrame support for gtk port

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 12 08:15:47 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=66280


Martin Robinson <mrobinson at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrobinson at webkit.org




--- Comment #7 from Martin Robinson <mrobinson at webkit.org>  2011-09-12 08:15:48 PST ---
(In reply to comment #5)

> There are some reasons.  
> At the first time scheduleAnimation is called, we don't need to wait 16ms to update first scene. 
> Using g_timeout_source_new(16) here is valid in the best case. However let's suppose that the content is too heavy or system performance is too low, so that the system can't support 60fps. It means it takes more time than 16ms to update next scene. In that case we have to call timerFiredCallback without extra delay to show better fps.
> For instance, if it takes 30ms to be called scheduleAnimation again from first call, then next scene will be updated after 46ms(30 + 16)) from first update. Here we don't need to waste extra 16ms.

Isn't starving the main loop a problem if you use 0 second timeouts?

(In reply to comment #6)
> (In reply to comment #5)
> > (From update of attachment 106114 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=106114&action=review
> > 
> > Thank you for review. :)
> > I'm not convinced sharing code between WebKit1 & WebKit2 is possible and better way. But let me consider more.
> 
> Yes, it should be possible.

Please do! 

> > >> configure.ac:935
> > >> +
> > > 
> > > Why not enable it by default?
> > 
> > I think this feature is experimental yet. Formal spec is not fixed so that we may need to modify this later.
> > But I don't mind changing default = yes.
> 
> I think it's harmless, what do you think Martin?

It's a bad idea to enable experimental features by default, because we might end up breaking ABI (of a sort) if the feature is removed or changed. Disabling it by default protects us a bit from that. Immature features are also less secure, I'd say.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list