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

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Carlos Garcia Campos <cgarcia at igalia.com>  2011-09-12 00:46:50 PST ---
(In reply to comment #5)
> (From update of attachment 106114 [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.

> >> 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?

> >> Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp:673
> >> +}
> > 
> > Maybe we could implement the animation stuff here, so that we don't need to add a new signal to web view.
> 
> Yor're right. My first implementation was like you mentioned.
> But I moved code from ChromeClient to webview after seeing cmarrin's patch for mac port (bug59146). Is it better maintaining consistency among ports?

I think it's that important at this level, but if you still want the implementation in WebView, add a private method instead of adding an undocummented signal to the API.

> >> Source/WebKit/gtk/webkit/webkitwebview.cpp:1369
> >> +
> > 
> > I don't understand this. The first time you create a timeout surce with 0, to be dispatched inmediately (I think you could use a g_idle_source() instead), but in the callback you check whether if elapsed time is 16ms, why not schedule a 16ms timeout here instead? I guess the first time timerFiredCallback is called it will always schedule a new timeout source.
> 
> 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.

I still don't see whay you need to create a new source and attach it to the context manually, instead of just using g_idle_add() or g_timeout add(). Would it be possible to use g_idle_add() for the first time and schedule a g_timeout callback that will be called every 16ms, so that you don't need to keep track of elapsed time?

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