Differences of VSYNC usage in Android and Aura (--enable-begin-frame-scheduling)

556 views
Skip to first unread message

hongb...@chromium.org

unread,
May 10, 2015, 12:24:50 AM5/10/15
to graphi...@chromium.org, hongb...@qq.com
Hi, graphics-dev

As you may know, --enable-begin-frame-scheduling option is provided to allow use a BeginFrame signal from browser to renderer to schedule rendering, and on Android, this option is turned on by default, so that the rendering pipleline is drived by vsync signal, this is to say, once browser thread received a VSYNC signal from Choreographer, it will 1) send BeginFrame to renderer in RenderWidgetHostViewAndroid::OnVSync; 2) CompositorImpl::OnVSync will post a composite task if needed.

However, the rendering pipeline for aura is a bit different from that for Android, for example, there is no RenderWidgetHostViewAura::OnVSync for aura impl, and also there is no ui::Compositor::OnVSync to let browser thread handle vsync signal. Moreover, if you turn on --enable-begin-frame-scheduling option, it will fail to render the web page.

My question here is, is there any special considerations for Aura not using VSYNC in the same way as Android does? Performance consideration or something else?

Thanks in advance.

Jared Duke

unread,
May 10, 2015, 1:20:44 AM5/10/15
to Hongbo Min J, hongb...@qq.com, graphics-dev, schedu...@chromium.org

+scheduler-dev

To unsubscribe from this group and stop receiving emails from it, send an email to graphics-dev...@chromium.org.

Simon Hong

unread,
May 10, 2015, 1:56:27 AM5/10/15
to Jared Duke, Hongbo Min J, hongb...@qq.com, graphics-dev, schedu...@chromium.org
Hi hongbo.min,

Currently, chromium on aura doesn't send BeginFrame message from browser to renderer.
So, renderer generates synthetic BeginFrame messages by itself.
If you turns it on, renderer is using ExternalBeginFrameSource instead of SyntheticBeginFrameSource.
ExternalBeginFrameSource just deliver BeginFrame message from browser to renderer's compositor.
Browser process on aura can't send BeginFrame message for now, renderer can't receive BeginFrame message.

I'll plan to talk this subject in the BlinkOn4 :)

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CACq7L5Ovdy4SbshPOckLt74D9fczm%3DAT8FWLM8tcmW2ey0XNHw%40mail.gmail.com.

Simon Hong

unread,
May 10, 2015, 2:10:25 AM5/10/15
to Jared Duke, Hongbo Min J, Hongbo Min, graphics-dev, schedu...@chromium.org
I realised that I didn't answer of your last question.
For more better performance, we are currently working on for enabling that option on aura.
You can check the status in here(crbug.com/372086,  crbug.com/401331)

Sunny Sachanandani

unread,
May 11, 2015, 9:02:11 PM5/11/15
to Simon Hong, Jared Duke, Hongbo Min J, Hongbo Min, graphics-dev, schedu...@chromium.org
To expand on Simon's answer, here is how we deal with vsync on various platforms:

1. On Aura (Windows, Linux, ChromeOS) we don't rely on a vsync callback from the OS. Instead we query for the vsync timebase and interval on every SwapBuffers/PostSubBuffer call. See PassThroughImageTransportSurface::SwapBuffers for example. In each of these cases we use an abstract interface called VSyncProvider the implementation for which is platform specific - see OMLSyncControlVSyncProvider for instance. All of this happens in the GPU process. Once we get the GPU parameters we send them to the browser process which in turn sends them to each renderer. Each renderer has a SyntheticBeginFrameSource which adjusts itself based on the vsync parameters - see DelayBasedTimeSource.

2. On Mac we get the vsync parameters through the CVDisplayLinkOutputCallback in DisplayLinkMac. This lives in the browser process because of certain constraints of this API. The vsync parameters are distributed to the renderers on SwapBuffers similar to Aura. We probably could do something like Android here but we don't at the moment.

3. On Android (and WebView M43+) we get the vsync callback in RenderWidgetHostViewAndroid::OnVSync (and CompositorImpl::OnVSync). In this case however the renderers don't use a SyntheticBeginFrameSource and instead use an external BeginFrameSource - i.e. the BeginFrameArgs are sent over IPC from the browser to the renderer.

I hope this helps.

闵洪波

unread,
May 18, 2015, 11:03:49 AM5/18/15
to Sunny Sachanandani, Simon Hong, Jared Duke, Hongbo Min J, graphics-dev, scheduler-dev
Sunny, 

thanks so much for your detailed explanation. It is very useful to me. It is definitely what I want to know:)


------------------ 原始邮件 ------------------
发件人: "Sunny Sachanandani";<sun...@chromium.org>;
发送时间: 2015年5月12日(星期二) 上午9:01
收件人: "Simon Hong"<simo...@chromium.org>;
抄送: "Jared Duke"<jdd...@chromium.org>; "Hongbo Min J"<hongb...@chromium.org>; "闵洪波"<hongb...@qq.com>; "graphics-dev"<graphi...@chromium.org>; "scheduler-dev"<schedu...@chromium.org>;
主题: Re: Differences of VSYNC usage in Android and Aura (--enable-begin-frame-scheduling)
Reply all
Reply to author
Forward
0 new messages