The recording by CanvasDrawEventRecorder into the ring buffer is not thread-safe
and so must all occur on the same (main) thread.
In addition to that it sometimes needs to send IPC messages via the PCanvas
protocol, which also can only be done on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D71174
This also adds checks for the other side closing during the ReturnRead and
ReturnWrite loops.
Depends on D70336
Differential Revision: https://phabricator.services.mozilla.com/D70337
--HG--
extra : moz-landing-system : lando
It seems clear that we can get long delays waiting for Direct2D to process
things on occasion. So given that we now detect when the reader has closed,
instead of guessing at a suitably long timeout, waiting indefintely while it
hasn't closed seems like a better option.
This gives a similar behaviour to when this is just running in the content
process, because that just has to wait on any long running Direct2D calls.
Differential Revision: https://phabricator.services.mozilla.com/D62464
--HG--
extra : moz-landing-system : lando
If the other side crashed with AboutToWait set in CanvasEventRingBuffer then in
theory we could spin forever waiting for it to change.
Differential Revision: https://phabricator.services.mozilla.com/D61828
--HG--
extra : moz-landing-system : lando
This is generally around object creation failures and their subsequent lookup,
which can happen, for example, during device reset.
Differential Revision: https://phabricator.services.mozilla.com/D60888
--HG--
extra : moz-landing-system : lando
This also fixes the CanvasParent destruction on channel close and error,
which was broken due to IPDL changes between rebases.
Differential Revision: https://phabricator.services.mozilla.com/D37088
--HG--
extra : moz-landing-system : lando
Bob Owen