Fix re-rendering, using the same canvas, when rendering was previously cancelled (PR 8519 follow-up) #9853
Conversation
…y cancelled (PR 8519 follow-up) Currently if `RenderTask.cancel` is called *immediately* after rendering was started, then by the time that `InternalRenderTask.initializeGraphics` is called rendering will already have been cancelled. However, we're still inserting the canvas into the `canvasInRendering` map, thus breaking any future attempts at re-rendering using the same canvas. Considering that `InternalRenderTask.cancel` always removes the canvas from the map, I cannot imagine that we'd ever want to re-add it *after* rendering was cancelled (it was likely just a simple oversight in PR 8519). Fixes 9456.
|
/botio unittest |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/212081c3f93a455/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/204e09578412e4f/output.txt |
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/212081c3f93a455/output.txt Total script time: 5.37 mins
|
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/204e09578412e4f/output.txt Total script time: 9.27 mins
|
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/6795148b47fd719/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.215.176.217:8877/5dba25cedc9c032/output.txt |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/5dba25cedc9c032/output.txt Total script time: 23.47 mins
Image differences available at: http://54.215.176.217:8877/5dba25cedc9c032/reftest-analyzer.html#web=eq.log |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/6795148b47fd719/output.txt Total script time: 38.73 mins
|
|
The Windows "failures" were, most likely, caused by a Firefox update (version |
|
Good find! |
|
/botio makeref |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 1 Live output at: http://54.215.176.217:8877/4a62af3268f4c5d/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/60948248371dd77/output.txt |
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/4a62af3268f4c5d/output.txt Total script time: 21.36 mins
|
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/60948248371dd77/output.txt Total script time: 36.26 mins
|
…ncel Fix re-rendering, using the same canvas, when rendering was previously cancelled (PR 8519 follow-up)
Currently if
RenderTask.cancelis called immediately after rendering was started, then by the time thatInternalRenderTask.initializeGraphicsis called rendering will already have been cancelled.However, we're still inserting the canvas into the
canvasInRenderingmap, thus breaking any future attempts at re-rendering using the same canvas. Considering thatInternalRenderTask.cancelalways removes the canvas from the map, I cannot imagine that we'd ever want to re-add it after rendering was cancelled (it was likely just a simple oversight in PR #8519).Fixes #9456.