Closed Bug 1614635 Opened 2 months ago Closed 1 month ago

Remote canvas write timeout due to long D2D1 Flush.

Categories

(Core :: Graphics, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox75 --- fixed

People

(Reporter: bobowen, Assigned: bobowen)

References

(Blocks 2 open bugs)

Details

(Keywords: testcase)

Attachments

(2 files)

With instructions from tsmith, I found this using grizzly [1] to fuzz the Canvas 2D API.

The attached test case causes a 30+ second Flush [2] on my machine during a Snapshot for line:
try{imd9=ctx3.getImageData(161,82,-40,268);}catch(e){}

Currently with remote canvas it will timeout after a number of waits and this can then cause the Translation to crash.
In a previous change I added a check to make sure the other side is still alive by checking the IPDL channel, so I'm just going to remove the limit on the number of waits.
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.

I'm setting this to block Release not Nightly, because I think these sorts of waits are probably fairly extreme examples.

[1] https://github.com/MozillaSecurity/grizzly
[2] https://docs.microsoft.com/en-us/windows/win32/api/d2d1/nf-d2d1-id2d1rendertarget-flush

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.

Blocks: grizzly
Keywords: testcase
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/988672936c1b
Keep waiting on the remote canvas writer side while the reader hasn't closed. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
You need to log in before you can comment on or make changes to this bug.