New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 809769 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

do we need an ack mechanism between HitTestAgregator and HitTestQuery?

Project Member Reported by riajiang@chromium.org, Feb 6 2018

Issue description

Hey all! Creating this bug so that we can have a central place for discussions (had some separate discussions) and I also have some questions.

So we have two shmem buffers between HTA and HTQ, say SA and SB. IIRC, there was some concerns about whether this case would be possible: HTA finished writing to SA and sent HTQ a switch IPC to switch to SA; HTQ hasn't got the switch IPC yet so still reading from SB; before HTQ actually switches to SB, HTA got a notice to Aggregate() again so we are writing to SB in HTA while HTQ is still reading from it.

I was trying to see the sequence of calls (with OOP-D): (notes at the end of each stacktrace)

[116988:117137:0206/181037.222500:ERROR:compositor_frame_sink_support.cc(271)] void viz::CompositorFrameSinkSupport::SubmitCompositorFrame(const viz::LocalSurfaceId &, viz::CompositorFrame, mojom::HitTestRegionListPtr, bool *)
=> (we have just finished storing hit-test data in HitTestManager)
[116988:117137:0206/181037.232808:ERROR:display_scheduler.cc(247)] virtual bool viz::DisplayScheduler::OnBeginFrameDerivedImpl(const viz::BeginFrameArgs &)
=> (we call "begin_frame_source_->DidFinishFrame(this)" at the end of SubmitCompositorFrame)
[116988:117137:0206/181037.234017:ERROR:display_scheduler.cc(484)] bool viz::DisplayScheduler::AttemptDrawAndSwap()
=> (this will tell HTA to start aggregating)
[116988:117137:0206/181037.235275:ERROR:hit_test_aggregator.cc(59)] void viz::HitTestAggregator::Swap()
=> (HTA finished aggregating)
[116910:116910:0206/181037.235607:ERROR:hit_test_query.cc(50)] void viz::HitTestQuery::SwitchActiveAggregatedHitTestRegionList(uint8_t)
=> (HTQ finished switching pointer to shmem)
[116988:117137:0206/181037.236550:ERROR:display_scheduler.cc(507)] void viz::DisplayScheduler::DidFinishFrame(bool)
=> (continue with these block of calls again, SubmitCompositorFrame -> ... -> DidFinishFrame)


I'm not very familiar with the timing of when clients SubmitCompositorFrame (and all the BeginFrame, OnBeginFrame, DidFinishFrame etc. notifications timing), would it be guaranteed that when Viz service receives a new SubmitCompositorFrame call, the previous IPC (switch pointer to shmem) from HTA to HTQ should have already arrived at the client side?
 
Short answer is no. The renderer and browser aren't synchronized so there is no guarantee that when CompositorFrameSinkSupport::SubmitCompositorFrame() is called the browser has received the IPC to switch. There is also no guarantee the browser has received the IPC to switch before DisplayScheduler::OnBeginFrameDeadline() fires and starts DisplayScheduler::AttemptDrawAndSwap().
Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
Status: Fixed (was: Assigned)

Sign in to add a comment