标签：load possible optional isa actually asi ack system putc
Unified BeginFrame scheduling for Chrome
Status: http://crbug.com/401331 and http://crbug.com/416760
Original Author: simonhong@chromium.org
Second Revision Authors: simonhong@chromium.org tansell@chromium.org (mithro@mithis.com)
Reviewers: brianderson@chromium.org, skyostil@chromium.org, nduca@chromium.org
Motivation
We‘ve learned from previous study, Improved vsync scheduling for Chrome on Android, about how explicit BeginFrame notification message from browser to renderer can improve frame rate with input handling. We need to adopt this mechanism to other platforms such as aura or mac for improving performance and unified implementation on all platforms.
Goal
This document will propose new BeginFrame scheduling to achieve below goals.
○ https://codereview.chromium.org/619843002/ (done by @simonhong)
○ add forward_begin_frames_to_children in SchedulerSettings
○ https://codereview.chromium.org/723713003/ (done by @simonhong)
○ Refactoring is in progress (ProxyBeginFrameSource)
(https://codereview.chromium.org/845393002/ by @simonhong)
○ set true to forward_begin_frames_to_children in SchedulerSettings on browser side cc scheduler
○ Aura based implementation is WIP (https://codereview.chromium.org/775143003/ by @simonhong)
○ We don’t need vsync synchronization with renderer process on unified BeginFrame scheduling
○ (https://codereview.chromium.org/775143003/ by @simonhong)
○ Routes WindowAndroid::OnVSync to the scheduler in android
○ Routes Mac’s DisplayLink to the scheduler in MacOSX
○ Aura already sends vsync to browser compositor’s scheduler
○ Set true to use_external_begin_frame_source in SchedulerSettings and implements new external BeginFrameSources
○ vsync parameter is no longer used in renderer process
○ In normal situation, scheduler of renderer process on all platforms will rely on external BeginFrameSource
○ Use un-throttled mode when renderer is in background mode
○ Use un-throttled mode when renderer’s frame-rate should be adjusted
External dependencies
○ https://codereview.chromium.org/638653003/ (Done by @weiliangc)
○ https://codereview.chromium.org/344743002 (@simonhong is working on this)
Benefits from unified BeginFrame (@brianderson)
○ Implement latency feedbackWait for multiple active renderers to swap in the browser, rather than only picking up the first renderer to swap
○ betwr aeen renderend browser (i.e. SwapNack). If an active renderer misses the browser’s deadline, the browser can tell the renderer that it was too slow immediately
Terms
Sometimes, VSync and BeginFrame are used interchangeably. Below is my understanding about both terms in chromium code base.
You can easily think with above terms like this - “When browser process gets VSync notification from system, it send BeginFrame message to renderers to trigger their new frame if they needs”
Overall diagram (originated from tim’s)
https://docs.google.com/a/chromium.org/drawings/d/1WEj-6A-8FmJNIMbd9hvkvxAuOOTwQvkSjbKR79YCt-c/edit
Proposed implementations
Below diagram is more specific version of above diagram. Browser side scheduler ‘s BeginFrame message will be delivered to LTH and then ui::Compositor.
ui::Compositor will have BeginFrame observer list and it will toss BeginFrame to all observers which are DelegatedFrameHost. Whenever renderer side scheduler needs BeginFrame and doesn’t needed, its corresponding DelegatedFramHost will be added as an observer or removed.
Synchronising vsync params
We need to synchronize system’s vsync params with browser side scheduler when platform doesn’t support frame start callback. In this section, I’ll talk about how to modify current vsync update mechanism. Between browser process and renderer process vsync synchronization will be removed.
Current implementation
Proposed implementation
With our next generation BeginFrame scheduling, we don’t need to send vsync params to renderer anymore because browser will request BeginFrame explicitly to renderer.
On Aura, only browser scheduler needs to be updated with vsync params.
Browser-side cc::Scheduler will use SyntheticBeginFrameSource to get next BeginFrame because Windows and Linux doesn’t provide frame start callback. Also, we can remove CompositorVSyncManager which is owned by ui::Compositor because vsync synchronization doesn’t need anymore.[1] [2] Renderer process will only rely on BeginFrame message from browser process.
On MacOSX, we don’t need to update vsync params with browser’s Scheduler anymore. Instead, we can use CVDisplayLinkOutputCallback which is called whenever the display link wants to output a frame by registering vsync callback via CVDisplayLink. CVDisplayLink will invoke registered callback when it needed a new frame. This callback will feed next BeginFrame to browser’s scheduler with externalBFS.
On Android[3] [4] [5] , there is no change with regards to vsync update.
We will use this vsync from android platform and deliver it to compositor scheduler by using externalBFS like mac when android starts to use SingleThreadProxy + Scheduler.
VSync-Aligned input handling
IIUC, When SendBeginFrame() is called at RWHV, BufferedInput[6] [7] (jdduke@ wrote VSync-Aligned Bufferred Input) should be delivered to renderer first before send BeginFrame to renderer. So we can have more chance to handle these inputs in the next frame.
Implementation plans
Question?
1. Does we need to modify current android implementation[8] [9] ? (solved - yes we need!)
2. Does we need to consider this feature in single thread mode[10] [11] , too?
See cc/scheduler/begin_frame_source.h file.
BeginFrameObserver {
OnBeginFrame(BeginFrameArgs)
BeginFrameArgs LastUsedBeginFrameArgs()
}
Core functionality of the API, tells you that input has been processed and that now is a good time to begin rendering.
Notes: BeginFrame calls *normally* occur just after a vsync interrupt when input processing has been finished and provide information about the time values of the vsync times. However, these values can be heavily modified or even plain made up (when no vsync signal is available or vsync throttling is turned off).
LastUsedBeginFrameArgs exists because any non-trivial observer needs to store BeginFrameArgs for usage until it receives the next BeginFrameArgs. The observer is also the authoritative source on if the BeginFrameArgs is going to be used in some way.
This functionality enables;
○ Don’t also need store a copy of the args.
○ Correctly take into account dropped frames.
BeginFrameSource {
bool NeedsBeginFrames()
SetNeedsBeginFrames(bool)
DidFinishFrame(size_t remaining_frames)
AddObserver(BeginFrameObserver);
RemoveObserver(BeginFrameObserver);
}
Provides a level triggered system for enabling / disabling the generation of OnBeginFrame messages. The signal is level triggered to reduce IPC overhead when the source is not local to a process.
Provides async back pressure information into the source about how many frames are still in the process of being processed. Is useful if a source wants to keep only a single frame pending or other similar options. These messages might be delayed by IPC overhead, so should be used as informational only.
Normal observer interface, probably implemented with base::ObserverList.
ProxyBeginFrameSource
CompositorVSyncManager is essentially there because it receives information from 2 threads:
1- one "authoritative" frame rate from XRandR, on the UI thread
2- the latest rate + alignment from the GPU, on the compositor thread.
Yes, CompositorVSyncManager should be existed until it is changed to run on SingleThreadProxy.
Before that, ui::Compositor should maintain two options.
If it is running on ThreadProxy(CrOS), CompositorVSyncManager is used as now.
If it is running on SingleThreadProxy(aura and mac with delegated rendering), it will use new BeginFrame scheduling.
+sievers@chromium.org who may have some thoughts here as it relates to recent Android browser compositor changes.
I think it‘s either UpdateVSyncParameters() *or* BeginFrame(). For the render compositors, we use the latter and don‘t need to tell those compositors about vsync params.
For the browser compositor, we currently do our own scheduling, but there are patches in the works for switching this to SingleThreadProxy+cc-scheduler+BeginFrame-scheduling.
+sievers@chromium.org, Will android use cc-scheduler as a BeginFrame source when the enne‘s patch (makes SingleThreadProxy as a SchedulerClient) is landed? If so, we should also update vsync params with cc-scheduler.
+tdresser@chromium.org might be able to chime in here. A slight difference between Android and Aura is that Aura‘s gesture detector is more or less a singleton, whereas on Android (for content-targeted input) we have one detector per view.
As touch input buffering occurs *before* gesture detection in the pipeline, there may be some subtle differences in how BeginFrame serves as an input flush signal.
Aura has one gesture detector per aura::Window. (GestureRecognizerAura is a singleton, but it stores a mapping from aura::Windows to GestureProviderAura‘s)
What needs clarification here?
I‘m probably not the best person to speak on the ordering of the BeginFrame message and input.
Thanks for the write-up! It would be great if we could minimize the differences between the Android implementation and other platforms as much as possible. +sievers@chromium.org recently did some major cleanup on the Android browser side logic, so unifying it should be much easier now.
Thanks for reading, Sami!
I added proposed diagram for android, too.
Yes. All platforms are moving to Browser compositors that use SingleThreadProxy.
In this case, it‘ll actually be nice since you don‘t need to make a thread hop to get from the Scheduler to the RWHV‘s BeginFrameManager.
+brianderson@chromium.org, When browser compositor uses single thread + cc-scheduler, how we can get BeginFrame message? Does SyntheticBeginFrameSource take that role, too on main thread?
Unified BeginFrame scheduling for Chrome
标签：load possible optional isa actually asi ack system putc
原文地址：https://www.cnblogs.com/huangguanyuan/p/10073441.html
