Skip to content
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

Closed
RoxKilly opened this issue Oct 22, 2016 · 6 comments
Assignees
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@RoxKilly
Copy link

RoxKilly commented Oct 22, 2016

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 compiled
  • md-spinner should not use CPU resources once it is taken out of the DOM

What is the current behavior?

App uses AoT compilation (JiT is not affected) and has <md-spinner> in the template

  • High CPU usage even once the spinner is removed from the DOM
  • Zonetask.invoke calls window.requestAnimationFrame in an infinite loop, choking the CPU
  • Minimizing the browser brings CPU utilization down. Restoring does the opposite

What are the steps to reproduce?

app.component.html

<md-card-content *ngIf="loading">
    <md-spinner></md-spinner>
</md-card-content>
<md-card-content *ngIf="!loading">
    Content goes here
</md-card-content>

loading===true when AppComponent loads, so the spinner is shown. In ngOnInit, 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

<md-spinner></md-spinner>

with...

<md-progress-bar mode="indeterminate"></md-progress-bar>

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 with AoT 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

crisbeto added a commit to crisbeto/material2 that referenced this issue Oct 27, 2016
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.
crisbeto added a commit to crisbeto/material2 that referenced this issue Oct 27, 2016
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.
crisbeto added a commit to crisbeto/material2 that referenced this issue Oct 28, 2016
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.
@ivoviz
Copy link

ivoviz commented Oct 30, 2016

@crisbeto @RoxKilly The PR might just solve the problem I reported long ago (#1283) - just saying, since it's not referenced in the PR itself, but probably can be closed after it's merged.

@crisbeto
Copy link
Member

Yeah, let's see, I didn't mark it as "fixes" on purpose since it may not fix it completely.

hansl pushed a commit that referenced this issue Nov 1, 2016
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.
@jelbourn
Copy link
Member

jelbourn commented Nov 4, 2016

@RoxKilly an experimental release for alpha.10 with this fix is on npm under the @experimental tag- does the change improve what you had been seeing?

@jelbourn jelbourn added the P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent label Nov 4, 2016
@RoxKilly
Copy link
Author

RoxKilly commented Nov 7, 2016

@jelbourn alpha 10 experimental-yogurt has improved things a great deal. CPU and memory consumption are both down

@jelbourn
Copy link
Member

jelbourn commented Nov 7, 2016

Sounds good- I'll make this as closed by #1635 then which will be in the alpha.10

@jelbourn jelbourn closed this as completed Nov 7, 2016
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

No branches or pull requests

4 participants