From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
mInAsyncPaint is only needed because the code using CreateBuffer expects the
buffer to be locked when it is returned. This isn't necessary because we can
now lock in BeginPaint.
MozReview-Commit-ID: 8WazvBKMbvb
--HG--
extra : rebase_source : ec59ca27e88257bd8e6d384685bee8227f545b31
Now that BeginPaintBuffer and BeginPaint are both implemented by content client,
I think it makes sense to just merge them into one method. This simplifies the
interface clients have to use.
MozReview-Commit-ID: 8bjH6WcpZS9
--HG--
extra : rebase_source : c2aad6cd9d85f7dd09652ee253683f03825e95c6
This commit does some more cleanup on the content client class hierarchy.
Some methods were virtual or instance methods when they didn't need to be.
MozReview-Commit-ID: 2y2D3zYtYvM
--HG--
extra : rebase_source : ebd137e4a1ee8eba10467e987bd2d91ea44ca5a2
CapturedPaintState::mTarget is actually a dual draw target to the black and
white draw targets, so this code will have the white draw target cleared black
and then white. This isn't incorrect, it's just wasteful.
MozReview-Commit-ID: ItgiSmegPK6
--HG--
extra : rebase_source : 9c3c88f463087a75383f1940ddeef6bb68ec35c4
UpdateDestinationFrom actually only uses a rect, so it's best to not be
misleading and force the clients of it to do the conversion.
MozReview-Commit-ID: EsUv3apqnku
--HG--
extra : rebase_source : 6ee0f7454ac2ea21618a62a9ab906857384d0fdf
This organizes the rotated buffer declarations and adds some documentation.
MozReview-Commit-ID: 5r24RiUMM6o
--HG--
extra : rebase_source : 28045e2d6b19db1f31796b7119717d417ee2dd34
This could be a part of the previous commit, but I omitted it to keep the size
down. Just some updates to comments and documentation.
MozReview-Commit-ID: HkCOSIQhBNv
--HG--
extra : rebase_source : 665b6bbe18dcd409809d33e1be37a56c0dc304d7
This commit is the guts of the refactoring.
This commit removes rotated content buffer, and moves the necessary
functionality to content client. All content clients now do not inherit from
rotated content buffer, but contain a refptr to a rotated buffer.
For the basic content client, this is a DrawTargetRotatedBuffer.
For the remote content client, this is a RemoteRotatedBuffer.
The double buffered content client contains an additional RemoteRotatedBuffer
for the front buffer.
Each derived class of content client only needs to implement a method to
create its own rotated buffer. The rest is handled by the base content
client. The remote content clients still override some additional methods
to sync buffers and do IPC.
MozReview-Commit-ID: B9vcSi8UYhm
--HG--
extra : rebase_source : a727d5548b0167eb12676837b173355eb0dd38a5
This commit splits off the part of BeginPaint that makes the decision about
whether to keep the buffer, its surface type, its content type, and the regions
to invalidate or paint.
MozReview-Commit-ID: JcPlv8GiRpA
--HG--
extra : rebase_source : 73c2de46ac9e11437e6a52aadd1da56028a7d3ec
This commit adds a method to rotated buffer to perform the adjusting to the new
destination rect, and potential unrotating that may need to happen. The goal of
this is to simplify and prepare BeginPaint to be moved to content client.
MozReview-Commit-ID: B4qeZqLjORR
--HG--
extra : rebase_source : 8ee7fb96ce8f1207b73027bb1d171dabd5b35788
Miscellaneous cleanup, PaintState doesn't need to know this as no one uses
this information outside of the content client classes.
MozReview-Commit-ID: 6K8LxEPvp4V
--HG--
extra : rebase_source : 931f7726d2f8f1f5ab32b5cf8f9030aa39a64bff
Miscellaneous cleanup, ContentClientSingleBuffered doesn't need to track if
the front and back buffer differ.
MozReview-Commit-ID: IvAw0b92jsh
--HG--
extra : rebase_source : c6b2d91666338f1d222f783b7a14e9d3b0ad6802
This commit refactors part of BeginPaint to treat the new and old back buffer's
as rotated buffers. The goal of this is to simplify and prepare this function to
be moved out of rotated content buffer.
MozReview-Commit-ID: 5iHeMbCWfpo
--HG--
extra : rebase_source : 232b699ca5d906e4784338914ebddd510730c379
This adds a new implementation of rotated buffer, which is backed by draw
targets. This will be the rotated buffer that basic content clients use.
MozReview-Commit-ID: Knn79yEFnxN
--HG--
extra : rebase_source : 78201bbb31c76e2b8131d912600b55500ba4cbdb
The front buffer for a double buffered content client is really just another
rotated buffer, so it can simplify the code to use the class we just added.
The goal is to have the back and the front buffer using remote rotated buffers,
but this is a good first step.
Note: The front buffer is represented as a Maybe<RemoteRotatedBuffer> in this
commit, but in the future it will be a RefPtr. That can't be done yet, because
rotated buffer can't implement refcounting in addition to compositable client.
MozReview-Commit-ID: Czk3otkf1pb
--HG--
extra : rebase_source : b7cc399643295bb63efa86739f3dae29d3375ae6
This adds a new implementation of rotated buffer, which is backed by texture
clients. This will be the rotated buffer that remote content clients use.
MozReview-Commit-ID: 3Y776uk5mFG
--HG--
extra : rebase_source : 40acce3f4150c5f6f51bf73f0b3c7e974ed8fd72
Similar to the previous patch, more functionality can be moved to rotated
buffer and out of rotated content client.
MozReview-Commit-ID: FNqfonyBBq9
--HG--
extra : rebase_source : fce8c6212321e6e25dc414c517a28e1e3c747c25
UpdateDestinationFrom is a useful method for any rotated buffer. This will be
needed when content clients are no longer rotated buffers.
Note: EnsureBuffer and EnsureBufferOnWhite were moved out of
UpdateDestinationFrom because I'd like to kill those methods, and so the calls
were moved to all users of UpdateDestinationFrom.
MozReview-Commit-ID: 2e3HhUsZ6iw
--HG--
extra : rebase_source : dd8f5a52808924a64ea0eb17359b6b749426b64e
This class doesn't seem to be necessary and only complicates the class
hierarchy.
MozReview-Commit-ID: 6dRXce1vB9T
--HG--
extra : rebase_source : 71591b44c68f9c8b73c7aadb6be245caaec0fbb5
Some css filter codes only used in layers-full mode. Since layers-full
already removed, we can also remove those unused codes.
MozReview-Commit-ID: 8YrfOfuXHNt
--HG--
extra : rebase_source : e9475d9100fbc2e5b301833f31fde1db458117aa
Most cases where the pointer is stored into an already-declared variable can
trivially be changed to MakeNotNull<T*>, as the NotNull raw pointer will end
up in a smart pointer.
In RAII cases, the target type can be specified (e.g.:
`MakeNotNull<RefPtr<imgFrame>>)`), in which case the variable type may just be
`auto`, similar to the common use of MakeUnique.
Except when the target type is a base pointer, in which case it must be
specified in the declaration.
MozReview-Commit-ID: BYaSsvMhiDi
--HG--
extra : rebase_source : 8fe6f2aeaff5f515b7af2276c439004fa3a1f3ab
2017-10-20 18:25:33 +11:00
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
It appears that in this case just waiting for the APZ flush to complete was
insufficient, probably because the APZ flush and touch inputs go via different
IPC channels and therefore do not provide ordering guarantees. So instead of
waiting for the APZ flush, let's just wait until the touchstart is received
in the content process and use that to resume the test.
MozReview-Commit-ID: AcPRhox1Xkg
--HG--
extra : rebase_source : be6653c7835d9a61bdc215266367adcc8adf8f0b
The two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
There's no way to handle this failure, so pass it to Unused.
MozReview-Commit-ID: 37PS9TsPqx7
--HG--
extra : rebase_source : f385f4c50d5407b1929abed7dae123f9570d2205
