-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
[spinner @alpha 9] AoT compilation causes high CPU use via requestAnimationFrame() #1570
Comments
Currently the progress circle hits ZoneJS on every animation frame, due to `requestAnimationFrame`. This change: * Wraps the `requestAnimationFrame` calls in `runOutsideAngular` in order to avoid hitting the change detection on every frame. * Switches from using an attribute binding to manipulating the `path` node directly. Referencing angular#1570, angular#1511.
Currently the progress circle hits ZoneJS on every animation frame, due to `requestAnimationFrame`. This change: * Wraps the `requestAnimationFrame` calls in `runOutsideAngular` in order to avoid hitting the change detection on every frame. * Switches from using an attribute binding to manipulating the `path` node directly. Referencing angular#1570, angular#1511.
Currently the progress circle hits ZoneJS on every animation frame, due to `requestAnimationFrame`. This change: * Wraps the `requestAnimationFrame` calls in `runOutsideAngular` in order to avoid hitting the change detection on every frame. * Switches from using an attribute binding to manipulating the `path` node directly. Referencing angular#1570, angular#1511.
Yeah, let's see, I didn't mark it as "fixes" on purpose since it may not fix it completely. |
Currently the progress circle hits ZoneJS on every animation frame, due to `requestAnimationFrame`. This change: * Wraps the `requestAnimationFrame` calls in `runOutsideAngular` in order to avoid hitting the change detection on every frame. * Switches from using an attribute binding to manipulating the `path` node directly. Referencing #1570, #1511.
@RoxKilly an experimental release for alpha.10 with this fix is on npm under the |
@jelbourn |
Sounds good- I'll make this as closed by #1635 then which will be in the alpha.10 |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug, feature request, or proposal:
Bug
What is the expected behavior?
md-spinner
should not use more CPU when app is AoT compiled than when it is JiT compiledmd-spinner
should not use CPU resources once it is taken out of the DOMWhat is the current behavior?
App uses AoT compilation (JiT is not affected) and has
<md-spinner>
in the templateZonetask.invoke
callswindow.requestAnimationFrame
in an infinite loop, choking the CPUWhat are the steps to reproduce?
app.component.html
loading===true
whenAppComponent
loads, so the spinner is shown. InngOnInit
, after data fetched from the server is received,loading=false
. The spinner disappears but CPU utilization remains high. This only affects AoT app (not in-browser compiled JiT app).I replaced
with...
and I no longer experience the problem.
What is the use-case or motivation for changing an existing behavior?
This makes
md-spinner
too costly to use withAoT compilation
Which versions of Angular, Material, OS, browsers are affected?
Tested on
Angular 2.0.1
,@angular/compiler-cli 0.6.4
,Material 9-3
,Firefox 49
,Chrome 54
,Windows 7 x64
Is there anything else we should know?
Get more details from this issue
The text was updated successfully, but these errors were encountered: