The following commits added the necessary tracking to ensure we always end
a profiler marker when we start one, and this just plugs them in.
MozReview-Commit-ID: C5VXpnlH2QA
--HG--
extra : rebase_source : 832c8abdef45e0a9bbb71bbf105fe4a76d0eb60d
This commit adds instrumentation and some asserting to track a "paint group",
which is essentially the first PaintThread::AsyncPaintContents until
PaintThread::AsyncEndLayerTransaction.
I didn't add an AsyncBeginLayerTransaction and use that to start a "paint group"
as I think it makes sense to not have a paint marker if we don't do
any painting.
MozReview-Commit-ID: AlSsUUF5ZOH
--HG--
extra : rebase_source : 84d9feaf5aac39fb9ce32984efda704fa2a68838
I believe this is the only case where we miss calling EndLayerTransaction,
but still had queued async paints. This wasn't an issue before, because
the following transaction would then do the synchronization. But I'd
like to use EndLayerTransaction for a profiler mark, so we should call
it unconditionally.
MozReview-Commit-ID: 9rUXBzCZaLO
--HG--
extra : rebase_source : ba360f2451190cf38745121d4dc32f4ed8d1bfe2
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Even if we cannot reuse the back buffer, we still use it to initialize the new back buffer.
The correct condition for detecting changes to buffer mode should only care if there is a
buffer, not if we decided to reuse it.
If the buffer mode has changed to component alpha, we need to invalidate and repaint everything
because we won't be able to copy over content to the new buffer correctly.
I believe this is a regression from the refactoring that created this function from
RotatedContentBuffer::BeginPaint.
MozReview-Commit-ID: H9G7GxqekLt
--HG--
extra : rebase_source : afb3321694ce3f1b54ad4dce28b4a7c7c7b47904
extra : amend_source : fdef1994514fcc9b9f2e952767a785841e9ddda0
extra : histedit_source : 3e8324255f516094c242ab3ec0688d2285c85a99
Add a new TextureClientData type, AndroidNativeWindowTextureData,
backed by a SurfaceTexture in single-buffer mode. It uses the
NativeWindow API, which provides producer-side access to the buffer.
This provides a DrawTarget which can be used to paint directly in to
the SurfaceTexture, which can then be composited using a SurfaceTextureHost.
Due to API restrictions it is not possible to read from a NativeWindow
while the corresponding SurfaceTexture has ownership of the
buffer. TiledContentClient now handles that by painting the additional
region that it cannot copy from the front buffer, if required.
MozReview-Commit-ID: 1NZq6MQqwFq
--HG--
extra : rebase_source : 9d1db721d4892f3df033d43127489a85421e8863
Csoregi Natalia
Lee Salzman
sotaro
Sebastian Hengst
David Anderson
Ryan Hunt
Margareta Eliza Balazs
JerryShih
Kartikaya Gupta
Chris Peterson
Jonathan Kew
Attila Craciun
Ethan Lin
Jeff Muizelaar
Jeff Gilbert
Andrew Osmond
James Willcox
Bas Schouten
Jamie Nicol