There are up to two compositor threads spawned - one in the GPU process
and one in the UI/chrome process. If the GPU process is used, then
failing to start the UI compositor thread is not fatal -- unless the GPU
process crashes too much and we fallback to the UI/chrome process. If
the GPU process compositor thread failed to start, then the GPU process
will crash and either restart, or fallback to the UI/chrome process
thread. If both fail, then Firefox crashes as expected.
Before we would not setup a content process properly unless the
UI compositor thread was active, even when using the GPU process. Now we
do, which allows the browser to be fully functional. Additionally when
shutting down, we ignore the lack of a compositor thread to permit a
graceful shutdown. In a future patch we will ideally we would not spawn
the compositor thread in a process until we actually need it, and
release assert on its failing to start.
Currently, the device-reset flow doesn't notify the decoder for device change
immediately. The decoder might use an invalid sync-object for synchronization.
Then, we will hit some assertions.
This patch try to make the synchronization flow become fallible, then we could
pass the error to the media framework for error handling.
MozReview-Commit-ID: BFY32MmOdt0
Use MOZ_CRASH, MOZ_CRASH_UNSAFE_OOL, or MOZ_CRASH_UNSAFE_PRINTF instead.
MozReview-Commit-ID: 1kCCHMlgbGP
--HG--
extra : rebase_source : 2f07ced16bccebf30cd3b2b5fea35e9868d32dad
extra : source : 0bf2c8425b828e71de55dd175fd0dad635b4e67d
This is essentially a no-op but it does silence the following warning
whenever the *.pb.* files are re-generated:
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: LayerScopePacket.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
MozReview-Commit-ID: 6L1TXHLcjsj
--HG--
extra : rebase_source : c88211414242c921eeefec27476c4a52e6c0974a
Bug 1092294 introduced a regression in to the code to copy from
the discarded front buffers to the new backbuffers in
SingleTiledContentClient. The aim was to ensure that if locking the
the frontbuffers failed, meaning the region could not be copied, that it
would be painted instead. However due to incorrect logic the
region would both be copied and painted in cases where
there was no onWhite buffers.
To fix this we take both locks (frontLock, and frontOnWhiteLock if
required) up front, so that we either copy both buffers or neither.
MozReview-Commit-ID: 3iepOuweruk
--HG--
extra : rebase_source : 2e2f951c3315f2809191f43a9d5ec4a939c82724
- This IPC is no longer used and can be removed to simplify
the PVRManager protocol.
MozReview-Commit-ID: Kno5CHkI17K
--HG--
extra : rebase_source : 227e36b00bc2d6a3b83b48d80fbfdfe35196057d
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : c14b9da390e88907e184409404c5c21b5fe23dff
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 3e8b49d5931d853857dd1b2eeff914465251f613
To sync the back buffer with the front buffer, we set the back buffer rect and
rotation to the front buffer's, and then copy over the pixels that different.
We used to do the updating of the rect and rotation before BeginPaint, but that
isn't necessary and we can move it to be with the copying of pixels.
MozReview-Commit-ID: HzBKvMZkn1
--HG--
extra : rebase_source : b5f5a0c46c225b8d2fbdd1891a16f3c0812382eb
This commit is an optimization for double buffering that delays the creation of
a back buffer until we know what kind of content type it needs to be.
Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint,
then in BeginPaint we could determine that we actually needed a different kind
of buffer because the content changed type, and recreate it.
This was needed because BeginPaint would copy the old front buffer to the buffer
created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had
determined we couldn't reuse the buffer, we would create a new one and copy that
"temporary" back buffer over, and use the new one.
This is unnecessary because we only need read access on that "temporary" back
buffer, and so we can just use the current front buffer instead.
This optimization only affects the double buffered case, and the single buffered
or basic cases should remain the same.
Note: Because we now need the front buffer for copying into the new back buffer,
we cannot Clear() it away in some error cases.
MozReview-Commit-ID: 2hyrrUhA4zO
--HG--
extra : rebase_source : 8eb7f992758d2e1db47eb88fe8d31651b335be6d
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 22c004e81257bf2d31438972c17b7b4f61532b23
Sebastian Hengst
vincentliu
Jeff Gilbert
sotaro
Randall Barker
Lee Salzman
Andrew Osmond
David Anderson
James Willcox
Ethan Lin
JerryShih
Markus Stange
Chris Peterson
NARCIS BELEUZU
Francois Marier
Jamie Nicol
Phil Ringnalda
Daosheng Mu
Botond Ballo
Kearwood "Kip" Gilbert
Jeff Muizelaar
Ryan Hunt