-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
line chart: better WebGL edge case handle #5465
Conversation
@@ -84,6 +84,11 @@ export interface ObjectRenderer<CacheValue = {}> { | |||
destroyObject(cachedValue: CacheValue): void; | |||
|
|||
setUseDarkMode(useDarkMode: boolean): void; | |||
|
|||
/** | |||
* Disposes rendering context. After invocation, renderer will never be used. |
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.
"will never be used" or "should never be used"?
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.
This is indicating to the implementer of renderer that one should expect that the renderer will no longer be used ever after dispose
is called. should never be used
sounds like an instruction to a user of the renderer. 🤔
I could see this jsdoc being used for both cases. Adopted your phrasing instead.
This change makes two improvements to WebGL support for the line chart. 1. Better feature detection. We now also listen to `webglcontextcreationerror` which gets emitted when browser fails to create webgl context from a canvas. This can be a good indication that user's system may not be able to handle WebGL renderer. 2. Better removal of JavaScript object. When an Angular components get scrapped, we get a chance to clean more stuff up. With the signal, we now instruct Three.js renderer to dispose all the objects more explicitly for better freeing of WebGL context + Three.js objects. There is no great way to unit test to guarantee correctness of the utility and the operation. Thus, we will leave such test to an integration test that would exercise browser capabilities. For now, we are happy with a manual functional test.
This change makes two improvements to WebGL support for the line chart. 1. Better feature detection. We now also listen to `webglcontextcreationerror` which gets emitted when browser fails to create webgl context from a canvas. This can be a good indication that user's system may not be able to handle WebGL renderer. 2. Better removal of JavaScript object. When an Angular components get scrapped, we get a chance to clean more stuff up. With the signal, we now instruct Three.js renderer to dispose all the objects more explicitly for better freeing of WebGL context + Three.js objects. There is no great way to unit test to guarantee correctness of the utility and the operation. Thus, we will leave such test to an integration test that would exercise browser capabilities. For now, we are happy with a manual functional test.
This change makes two improvements to WebGL support for the line chart. 1. Better feature detection. We now also listen to `webglcontextcreationerror` which gets emitted when browser fails to create webgl context from a canvas. This can be a good indication that user's system may not be able to handle WebGL renderer. 2. Better removal of JavaScript object. When an Angular components get scrapped, we get a chance to clean more stuff up. With the signal, we now instruct Three.js renderer to dispose all the objects more explicitly for better freeing of WebGL context + Three.js objects. There is no great way to unit test to guarantee correctness of the utility and the operation. Thus, we will leave such test to an integration test that would exercise browser capabilities. For now, we are happy with a manual functional test.
This change makes two improvements to WebGL support for the line chart.
webglcontextcreationerror
which gets emitted when browser fails tocreate webgl context from a canvas. This can be a good indication
that user's system may not be able to handle WebGL renderer.
scrapped, we get a chance to clean more stuff up. With the signal, we
now instruct Three.js renderer to dispose all the objects more
explicitly for better freeing of WebGL context + Three.js objects.
There is no great way to unit test to guarantee correctness of the
utility and the operation. Thus, we will leave such test to an
integration test that would exercise browser capabilities. For now, we
are happy with a manual functional test.