View Issue Details

IDProjectCategoryView StatusLast Update
0015267MMW 5Main Panelpublic2019-10-25 00:57
ReporterLudek Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015267: Optimize animations to be less CPU intensive
DescriptionCurrently 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

TagsNo tags attached.
Attached Files
Fixed in build2208

Relationships

related to 0015258 closedpetr CPU Utilization sometimes stays at 50% on certain nodes 
related to 0016048 closedLudek Endless dummy progress tasks (regression in 2206) 

Activities

Ludek

2018-12-17 15:13

developer   ~0051806

Last edited: 2018-12-17 15:15

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.)

michal

2018-12-17 15:20

developer   ~0051807

Used for visualizations in build 2142.

michal

2018-12-17 16:28

developer   ~0051808

Resolving, NP view animation is already using transformations, i.e. GPU where possible.

peke

2018-12-21 01:09

developer   ~0051853

Verified 2143

peke

2019-02-06 02:48

developer   ~0052410

Re Verified 2154

Closing CPU Levels are normal.

rusty

2019-10-23 14:41

administrator   ~0055076

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).

Ludek

2019-10-23 19:26

developer   ~0055079

Last edited: 2019-10-23 20:46

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?

Ludek

2019-10-23 20:36

developer   ~0055081

Last edited: 2019-10-23 20:36

Implemented BROKEN CIRCLE in build 2208

Looks good IMO:

circle.png (38,022 bytes)   
circle.png (38,022 bytes)   

peke

2019-10-24 19:32

developer   ~0055109

Verified Broken Circle implementation in 2208

I agree it looks good, kind of futuristic.

rusty

2019-10-24 19:56

administrator   ~0055110

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!

rusty

2019-10-24 20:00

administrator   ~0055111

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

Ludek

2019-10-24 21:36

developer   ~0055113

Last edited: 2019-10-24 21:48

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.

rusty

2019-10-25 00:57

administrator   ~0055114

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.