[Webkit-unassigned] [Bug 99592] Add WebGraphicsContext3D::WebGraphicsUpdateVSyncTimeCallbackCHROMIUM

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Ali Juma <ajuma at chromium.org>  2012-10-17 14:14:39 PST ---
(In reply to comment #2)
> (From update of attachment 169172 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=169172&action=review
> 
> > Source/Platform/chromium/public/WebGraphicsContext3D.h:145
> > +    class WebGraphicsUpdateVSyncTimeCallbackCHROMIUM {
> 
> why do you need this? Can't you use the output surface system?

One big advantage of the new approach is that it works without modification for sending vsync updates to renderers on desktop Linux (whenever OML_GLX_sync_control is available). The downside of adapting this approach to go through the existing path is that the result will be Aura-specific.

To avoid having two different paths for updating vsync state, we could move the existing code to the new path. This would mean that the GPU process would always be responsible for pushing out vsync updates to all compositors; in situations (as we currently have) where the browser process is the original source of this information, the browser would send the information to the GPU process and the GPU process would pass it on to renderers. Thoughts on this?


(In reply to comment #1)
> (From update of attachment 169172 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=169172&action=review
> 
> > Source/Platform/chromium/public/WebGraphicsContext3D.h:147
> > +        virtual void onUpdateVSyncTime(int64_t) = 0;
> 
> Do you need two arguments (one for phase and one for frequency)?

Yes, there should also be an argument for frequency (but note that OML_GLX_sync_control is currently not providing frequency information on Chrome OS devices).

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