View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015267 | MMW 5 | Main Panel | public | 2018-12-15 08:57 | 2019-10-25 00:57 |
Reporter | Ludek | Assigned To | |||
Priority | urgent | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 5.0 | ||||
Target Version | 5.0 | Fixed in Version | 5.0 | ||
Summary | 0015267: Optimize animations to be less CPU intensive | ||||
Description | Currently even simple circle progress animation (progress.svg) is quite a lot CPU intensive (0015258) There seems to be some trick how to optimize it (or delegate the work from CPU to GPU): https://stackoverflow.com/questions/13176746/css-keyframe-animation-cpu-usage-is-high-should-it-be-this-way https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108 | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Fixed in build | 2208 | ||||
|
Used the trick (with transform: translateZ(0)) to force GPU usage. Used for progress.svg and the basic animations (zoom in / zoom out / slide in / slide out). Tested on my machine (i7) for the large progress.svg (in Folders subview) and it reduced CPU usage from 8% to 5%. => used in 2142 Assigned to Michal to evaluate the usage for playback visualization and others animations (like Now Playing large etc.) |
|
Used for visualizations in build 2142. |
|
Resolving, NP view animation is already using transformations, i.e. GPU where possible. |
|
Verified 2143 |
|
Re Verified 2154 Closing CPU Levels are normal. |
|
Re-opening based on skype discussion: 0016048 shows that the cpu utilization associated with the 'progress wheel' is stick quite high, so it was suggested that: 1) if possible, it should be further optimized and/or not use SVG 2) If the above isn't possible, then in cases where the status bar and the progress wheel are both displayed, then the progress wheel doesn't need to show (or be animated)--although there needs to be a mechanism to toggle the status bar on/off (normally this is done by clicking the progress wheel so if the progress wheel isn't shown, toggling the status bar off would have to be done by clicking on the status bar). |
|
Based on my today's tests the current progress circle animation (of the same dimensions as is on the toolbar) takes roughly 3% of my CPU on my machine See: https://jsfiddle.net/ehoud3j1/ - FADING BALLS https://jsfiddle.net/o2rmgz4h/ takes roughly 1 % - FADING LINES https://jsfiddle.net/q2btr9h7/ also takes roughly 1 % - BROKEN CIRCLE https://jsfiddle.net/ovac3swh/ also takes roughly 1 % And at dimension 512 x 512 px - current takes 6% - https://jsfiddle.net/u5rja9kt/ - FADING BALLS takes 2% - https://jsfiddle.net/wvdtmLhe/ - FADING LINES takes 2% - https://jsfiddle.net/q2btr9h7/1/ - BROKEN CIRCLE takes 2% - https://jsfiddle.net/uj0zs1gy/ So either of the above is 3 times less CPU intensive than the current one. I would prefer "BROKEN CIRCLE" from the design/visual perspective? |
|
Implemented BROKEN CIRCLE in build 2208 Looks good IMO: |
|
Verified Broken Circle implementation in 2208 I agree it looks good, kind of futuristic. |
|
Significant improvement and it looks great! I'm not sure if this makes sense but processes such as scanning, which display the progress wheel, seem to run faster now! |
|
I noticed a strange problem--although the wheel renders correctly in the upper-right corner, when it displays in the tree (e.g. for Downloads), the 11am and 2pm positions seem to move by a pixel on each rotation. See: https://www.screencast.com/t/yLpdP9opd |
|
Ok, I see. But is this really an issue? Re scanning: it is faster because of another optimization that I have made re progress bar updating. |
|
The animation glitch is pretty minor, so I'll close this issue--we can address the glitch in the future as a low priority item. |