The important part here is that the test parent page
(test_bug1151663.html) waits for paints to complete before spawning the
helper window. Otherwise, the helper window might think it's done
painting (because it is) and start running the test even though its
layer tree has not been attached to the chrome layer tree. In such a
scenario reading the APZ test data produces an empty tree for the
content layers id and causes the test to fail.
This test was written before we had waitUntilApzStable so sprinkling some
of that into the test makes it more robust in general as well.
MozReview-Commit-ID: J8rqW6dcy23
--HG--
extra : rebase_source : f9e28bd15f355c88649ff1797b1f1205824bf815
When comparing a Maybe<WrScrollId> to another WrScrollId we need to properly
handle the case where Nothing() signifies the root scroll frame. This is
equivalent to calling scrollId.valueOr(FrameMetrics::NULL_SCROLL_ID), as was
done before WrScrolLId replaced ViewId in the WebRender ScrollingLayersHelper.
We also have DisplayListBuilder::TopmostScrollId always return a value instead
of a Maybe, since an empty clip stack means that the current scroll id is that
of the root scroll frame.
Previously Nothing() was not equivalent to WrScrollId { 0 }, which caused the
ScrollingLayersHelper to fill the mClipAndScroll value and push another
set of clip and scroll nodes onto the WebRender display list builder.
MozReview-Commit-ID: CeatZlRXtuI
It looks like the call chain is called ScheduleComposite on the client
LayerManager API, but then for some reason the functions in the IPDL
bridges are called ForceComposite, and then they eventually call the
ScheduleComposition function on the CompositorVsyncScheduler. This is
silly, so I renamed the IPDL bridge functions to ScheduleComposite as
well to be consistent.
MozReview-Commit-ID: D7bWpASaEtb
--HG--
extra : rebase_source : ecb0494d9461bd4ada48bfb602e7b518f0601c1b
This function is not overridden, so there doesn't seem to be any value
in making it virtual.
MozReview-Commit-ID: 8K34xTGtBc7
--HG--
extra : rebase_source : c7ad229f4b4de1a1ed8b8f8e782a21082c4abb12
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch changes this file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(The automated modeline.py script won't do this on its own for this one file. I
think that's because this file has the vim & emacs modelines in the reverse
order from the standard Mozilla syntax, and modeline.py is conservative and
won't change syntax that it doesn't immediately expect/understand.)
MozReview-Commit-ID: 7R1DUBEvFFh
--HG--
extra : rebase_source : eb802806375cf7d6f6fb0626220b1a510b375cdb
SetTestSampleTime is called from tests via the advanceTimeAndRefresh API
on DOMWindowUtils, and the expectation is that after it is done, the
time has been advanced and a composite has happened. So we need to
ensure that is the case with WebRender as well. This fixes the issue I
was seeing with test_group_hittest.html and makes it pass.
MozReview-Commit-ID: 86l9mTTwD2v
--HG--
extra : rebase_source : d2921fb0f9b09f4366fb516e4a6254a7f13f3e4e
This splits the FlushRendering function into sync and async versions
just for a bit more clarity. In the async version we don't want to set
the mForceRendering flag at all because we don't need to force a
rendering - if there is one already pending then that's good enough. And
anyway in practice the async version seems to only ever be invoked by
CompositorBridgeParent::SetTestSampleTime which I'll be changing in the
next patch.
MozReview-Commit-ID: 4cdU0U5B1pp
--HG--
extra : rebase_source : d7842844fca758d53121e3326d8da7fb7592ad8b
This extracts a code pattern that appears a couple of times in the code.
It occurs in CompositorBridgeParent as well but there's some extra stuff
involved there with the mOverrideComposeReadiness flag that I don't
understand so I'm leaving that as-is for now.
MozReview-Commit-ID: 2xqgaQZT4e1
--HG--
extra : rebase_source : 294727f146bbe5323a2cbdaa511dac5a4fc81571
GetGfxInfo returns an already_AddRefed, you can't just forget about its return
value.
MozReview-Commit-ID: Ia6pyJN9njf
--HG--
extra : rebase_source : 73f7f1a6a8093d6f6555fa11f784bf912e1ab616
SetNeedsComposite is only ever called from one place on the compositor
thread, but it has a bunch of generic boilerplate to handle being called
from any thread. If we inline it we don't need the extra boilerplate and
it's much simpler to follow the code.
MozReview-Commit-ID: E1AcMh80KsH
--HG--
extra : rebase_source : 717fe101a3b23e30f8443110de5b6bf1a84cddda
