However, I'm getting very low FPS when dragging the slider in Firefox on OSX (especially when dragging long distance in a short time). Is this due to the SVG rendering performance of Firefox or due to your code?
Turning off animations doesn't seem to make a difference.
To further improve things, I would suggest two changes to your webpack config:
1. Use the production version of React. It seems that you are using the slightly slower development version. (In webpack this is done by defining process.env.NODE_ENV = "production" and eliminating dead code afterwards)
2. Stop using webpack in development mode for your deployment. There are 272 eval() calls in your bundle because of this: https://raw.githubusercontent.com/zzarcon/react-circle/c1480...
Both of these things are already taken care of by the production mode in webpack 4.
Im using an external tool for deploying the site, created a PR there to use production mode, do you think that should be enough? Thanks! https://github.com/zzarcon/ts-react-toolbox/pull/2
The difficult part is usually to determine how much time is still needed for a computation.
My theory, also described in the blog post, and which I felt like the demo demonstrated when its JS worked, is that the nice thing about radial progress bars is that with spin and "tail" movement you can use a radial progress bar for composite progress (progress of multiple individual tasks with defined progress composited together, including cases of "task discovery" where progress may only start later).
I felt that when done right it doesn't violate user expectations ("forward momentum"), and it's an interesting merger of the spinner and progress bar that could be used in some pretty complicated situations.
I should get that demo working again.
But still: This is easy to understand (I think I got everything I'd need from the animated gif and the one code example). It looks like it's versatile and will save you at least half a day of googling, coding and testing (unless you are an expert in all technologies involved).
I upvoted it..
If you're going stateful to handle timers remember to use requestAnimationFrame
Don't use pie/circle diagrams.
Sorry I don't have a link to the pieces of research.
It's common from users to expect that when given an exact number for progress (35%) that percentages are themselves exact and evenly distributed. How many people hear bug reports that it took extra time to move from 36% to 37% than from 35% to 36%, or were worried that the system might have been stuck or crashed at 54% because it took so long, from someone trying to eagle eye your progress indicator?
Just because you can give a progress percentage doesn't mean that the user needs to know the exact value of that percentage or be able to visually compare progress indicators as strongly as possible.
To many times I’ve seen these kind of comments on GitHub, HN, ShowHN.
Our field is filled with people who lack a 101 in constructive feedback and context awareness and it breaks my heart. Who would like to ever contribute again if this was the response they got on their first contribution?
There is nothing wrong with making a post stating that you've found a bug. There is a problem with acting entitled like you are, and insulting the developer in the process.
so we're no longer allowed to criticize poor things we don't pay for?
This is a bad way to deliver criticism, especially on a ShowHN.
let me know if you still experience that issue
I'd recommend either killing that altogether as it definitely gives the perception of bad performance.
Or... at least take into account the delta of the progress change when doing animation. For instance, if going from 5 to 10%... a slower animation is fine. If going from 0 to 100%, the animation should be much quicker.
React profiles are not very easy to interpret but perhaps you're doing a lot more work per frame than you should be?
Here's the profile: https://perfht.ml/2F7ohwx
A lot of the work seems to be the React diffing? The only thing that changes between frames when dragging the slider is the style attribute.
Furthermore, the author seems to have included the development version of React. And the author used development settings for the webpack compilation. The compiled JS is full of eval() calls.
(Does not compute)
The think that myth is coming from the fact that JVM is heavy (150MB?), so it takes time to start, and hot-spot needs some iterations on a source code before it can fully apply JIT, but other that that, Java is really good.
It might just be that the ease-out transitions for the stroke are not efficiently implemented in whatever browser you're using.
If you've tried and check out and understand the code you'd see there's so little being done in JS that this stuff is surely not the bottleneck.
I suggest taking a look at Android’s views or even Flutter.