It is theorically possible that the WinCompositorWindowThread failed to start. Should this happen, attempting to shut it down will cause shutdown to hang forever.
Differential Revision: https://phabricator.services.mozilla.com/D32602
--HG--
extra : moz-landing-system : lando
BGRA may not be supported on GLES implementations, such as on the
Pixel 2 device. Since WR on Android uses GLES, we should use RGBA
when getting snapshots so that it actually works instead of failing
silently.
Differential Revision: https://phabricator.services.mozilla.com/D29060
--HG--
extra : moz-landing-system : lando
GeckoSurfaceTexture could bind to only one GL context at once. With WebRender, GeckoSurfaceTexture is soon bounded to sharedGL on render thread. It caused the problem if GeckoSurfaceTexture is rendered to WebGL. It could happen only for video's GeckoSurfaceTexture. To avoid the problem, the GeckoSurfaceTexture is bound to gl context when it is actually rendered on WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D27873
--HG--
extra : moz-landing-system : lando
The array takes up more space than a bitset, and we don't need to keep
duplicates anyway, so the set doesn't lose us anything.
Differential Revision: https://phabricator.services.mozilla.com/D27900
--HG--
extra : moz-landing-system : lando
We discussed this a bit in Orlando. Essentially, we want to run cleanup
operations in texture_cache before all documents' frames, and then be
able to ensure that every document generates a frame, because otherwise
we will run into problems with evicted cache items used by non-updating-
but-still-rendering documents. Accordingly, we need an endpoint to
lump all of the transactions that generate frames together. This adds
that and builds out all of the plumbing necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25132
--HG--
extra : moz-landing-system : lando
We discussed this a bit in Orlando. Essentially, we want to run cleanup
operations in texture_cache before all documents' frames, and then be
able to ensure that every document generates a frame, because otherwise
we will run into problems with evicted cache items used by non-updating-
but-still-rendering documents. Accordingly, we need an endpoint to
lump all of the transactions that generate frames together. This adds
that and builds out all of the plumbing necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25132
--HG--
extra : moz-landing-system : lando
We discussed this a bit in Orlando. Essentially, we want to run cleanup
operations in texture_cache before all documents' frames, and then be
able to ensure that every document generates a frame, because otherwise
we will run into problems with evicted cache items used by non-updating-
but-still-rendering documents. Accordingly, we need an endpoint to
lump all of the transactions that generate frames together. This adds
that and builds out all of the plumbing necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25132
--HG--
extra : moz-landing-system : lando
When SurfaceTexture is single buffer mode, UpdateTexImage() should be called only once for each publish. If UpdateTexImage() is called more than once, it causes hand on puglish side.
Differential Revision: https://phabricator.services.mozilla.com/D24483
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
RenderCompositorEGL is also used on wayland, but SharedGL is not enabled on wayalnd. Since SharedGL caused flickering, when multiple windows were opened on wayland.
Differential Revision: https://phabricator.services.mozilla.com/D23786
--HG--
extra : moz-landing-system : lando
By using WebRenderTextureHostWrapper for canvas, we could avoid triggering frame build on WebRender backend if WebRenderTextureHostWrapper is only change.
Differential Revision: https://phabricator.services.mozilla.com/D19896
--HG--
extra : moz-landing-system : lando
We lose some sugar but gain some safety. This seems like the right
trade. If people want sugar they should use Rust.
Differential Revision: https://phabricator.services.mozilla.com/D16918
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
The latter causes confusion in the memory reports because it gets summed
up and thus effectively doubles the reported texture memory usage. I've
decided it's best to drop, and so might as well do that while we're
already messing around with the memory reports and the associated
boilerplate.
Depends on D13439
Differential Revision: https://phabricator.services.mozilla.com/D13440
The latter causes confusion in the memory reports because it gets summed
up and thus effectively doubles the reported texture memory usage. I've
decided it's best to drop, and so might as well do that while we're
already messing around with the memory reports and the associated
boilerplate.
Depends on D13439
Differential Revision: https://phabricator.services.mozilla.com/D13440
--HG--
extra : moz-landing-system : lando
On the non-WR codepath, the COMPOSITE_TIME probe records the time spent
in CompositorBridgeParent::ComposeToTarget, which does all the
compositing work from vsync to when stuff shows up on the screen. The
equivalent on the WR codepath is spread over multiple threads, but the
start is in WebRenderBridgeParent::ComposeToTarget and the end is when
we decrement the pending frame count in RenderThread. So we can
instrument those sites to record the interval.
MozReview-Commit-ID: 5EMUzBT1f6x
--HG--
extra : rebase_source : eafa7ea9931a3d3fb17b95dc9b9e4aa4ff9ff566
I'm going to make this structure a little bigger in the next patch, so
to avoid the overhead of copying it around we can just store it on the
heap. I also switched to using a std::unordered_map since now the value
is just a pointer.
MozReview-Commit-ID: 2g1Eyu95W4Q
--HG--
extra : rebase_source : 8e78d72c2dad668d543deb9fc07371e74d9ac40f
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Instead of notifying the AsyncImagePipelineManager on the compositor
thread via the CompositorBridgeParent, we can send it the new pipeline
info directly from the RenderThread after the update happens. This
effectively splits the AsyncImagePipelineManager update-processing into
two parts: one that takes in the new pipeline info and one that process
it. This allows us to invoke the processing step from other code running
on the compositor thread, which we will need to do in the next patch.
MozReview-Commit-ID: 7xhm8I7bY4C
--HG--
extra : rebase_source : bfa62e326fd830bc2ef771138e5008fb2bc0d6b8
We do a silent upcast from CompositorBridgeParent* to the base class and
pass it around as a CompositorBridgeParentBase* for no reason. Avoiding
this simplifies the code slightly and avoids virtual function overhead.
We do need to move a couple of functions in CompositorBridgeParent from
protected scope to public scope.
MozReview-Commit-ID: 9Zq3GwxEXpr
--HG--
extra : rebase_source : 67346159e7d99ca7fc2fe0052e85aa6618b50d27
This also rearranges the method implementation slightly to make the next
patch easier to read. This patch should have zero functional changes,
it's just refactoring.
MozReview-Commit-ID: 53StJ0TH3IT
--HG--
extra : rebase_source : 2f3aeb54271da75a7e051afc24b8a4c96f8496f2
This prevents us from getting stuck in the frame throttling code where
TooManyPendingFrames always returns true.
MozReview-Commit-ID: 92tybPOaOTP
--HG--
extra : rebase_source : 8934f89a191759e85578db3dfde9e017a03a82eb
Instead of passing a WrPipelineInfo* to C++ code, we can now pass the
WrPipelineInfo directly. C++ code can access the info members without
having to call back into rust code, so the wr_pipeline_info* iterator
methods can be removed. Deleting the structure still requires passing it
back to rust.
MozReview-Commit-ID: HYcPX3mCGKW
--HG--
extra : rebase_source : f4b781cfc463c8e196f67a6e178ce4ce44a9464a
Patch originally attached to - and reviewed by sotaro on - bug 1432708.
MozReview-Commit-ID: LNWHtuFTPG5
--HG--
extra : rebase_source : c1694476cb454d914f2cfe3ec7cf55aaa0aacd4c
To avoid future issues, this is done by combining the Render and Update methods
into a single call. As a minor side-effect, timing in the parent method now
includes the time to run update.
MozReview-Commit-ID: GJ0l049eFRj
--HG--
extra : rebase_source : f9b4ee6f34bc45d87b3df40e5a25f3bfb2ec8068
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the 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
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b