You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating this issue reporting silent crashes during image exports I’ve come across a reproducible stack overflow when a PictureRecorder goes out of scope.
The example code below is a little contrived but mirrors the way I’m attempting to make PictureRecorder ‘restartable’, such that a picture can be generated and then additional drawing commands can be appended to it. My approach has been to start a new recording and immediately draw the output Picture to it, then start directing client commands to that new recording.
When Pictures are generated repeatedly, there are increasing levels of nesting, since each ‘restart’ of the PictureRecorder draws the Picture of its previous state (which in turn draws the Picture of its previous state, and so on). Note that It’s quite possible that this is an anti-pattern that I should abandon and if so would love suggestions for alternative approaches.
Here’s a test case that reliably triggers a stack overflow for me (though it wouldn’t surprise me if you need to adjust the loop range above 20k on other systems):
While investigating this issue reporting silent crashes during image exports I’ve come across a reproducible stack overflow when a
PictureRecorder
goes out of scope.The example code below is a little contrived but mirrors the way I’m attempting to make
PictureRecorder
‘restartable’, such that a picture can be generated and then additional drawing commands can be appended to it. My approach has been to start a new recording and immediately draw the outputPicture
to it, then start directing client commands to that new recording.When
Picture
s are generated repeatedly, there are increasing levels of nesting, since each ‘restart’ of thePictureRecorder
draws thePicture
of its previous state (which in turn draws thePicture
of its previous state, and so on). Note that It’s quite possible that this is an anti-pattern that I should abandon and if so would love suggestions for alternative approaches.Here’s a test case that reliably triggers a stack overflow for me (though it wouldn’t surprise me if you need to adjust the loop range above 20k on other systems):
And just to demonstrate that it’s related to the nested
Picture
drawing and not simply the number of drawing operations, this runs with no problem:The text was updated successfully, but these errors were encountered: