-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(): dispose-render concurrency #8220
Conversation
rename `isRendering` => `nextRenderHandle` introduce `destroy` instread of `dispose refactor `dispose` to call destroy after rendering finished
`canvas#toCanvasElement` used to kill requested renders
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Viewed the test logs
It is fixed!
DONE |
done b56685d |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated description
Added extensive tests
Ready!!
I earned 0.1% of testing coverage in this PR 🤓 |
task.kill = reject; | ||
if (this.__cleanupTask) { | ||
this.__cleanupTask.kill('aborted'); | ||
} | ||
|
||
if (this.destroyed) { | ||
resolve(false); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are we doing with those?
i see you want to resolve with true/false in case this is an effective dispose or not.
But why? what does it give us this extra information?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps someone needs to wait until dispose is done to trigger some task that shouldn't start if not disposed
This seems good to me and less invasive than the original. |
I wanted to abort the rendering once disposed is called. That is why I tried the first approach.
What happens now with
|
You mean maybe we should let the rendering happen even if the the |
What if we wrap |
This makes me prefer the previous approach |
@asturur please comment on the following before we proceed
Let's say we trigger a hot reload. I have to say that the prev approach is legit. You read it but I refactored it afterwards. |
handles the case in which there is a requested render and the dev calls `renderAll`
21246b2 safeguards |
I m not sure what will happen with a react binding made to dispose a canvas on element unmount for an hot reload. Also, if you are disposing a canvas, you should not reinitialize the same. Dispose is mostly to trash the instance and clean te resources. If you dispose on unmount, you are probably adding a new instance on mount? |
Correct. |
fabricjs#8220) Co-authored-by: Andrea Bogazzi <andreabogazzi79@gmail.com>
Description
Fixes a race condition between requested rendering and disposing
Reproduce
requestRenderAll
is calledChanges
isRendering
=>nextRenderHandle
destroy
acting instead ofdispose
dispose
to calldestroy
after rendering is finished - it has become an async method that return true if disposing has completed, false if the canvas was already destroyed or throws an error if it was aborted by a consequent calldestroyed
,disposed
flag that blocks rendering calls from executingcanvas#toCanvasElement
used to kill requested renders b12491dreplaces #8218