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).
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.
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.
Thanks for the feedback! You are right, the demo currently hangs quite a lot on Firefox, Im pretty sure the issue is actually not related with the component itself, I created a issue on the repo to fix it https://github.com/zzarcon/react-circle/issues/10 :)
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)
I think the author already patched it and that's why you're not seeing the same problem. Now it runs faster for me, too. (But HN doesn't allow me to edit my original comment anymore)
This is my feedback on extremely poor performance of this single reactive component. I hope developer of this component never makes a single webpage. If a single component is that slow and unresponsive, as you see on my video, the webpage (or even worse MOBILE APP) would probably require 16 core Ryzen to render smoothly and scroll up and down on it.
I play on this laptop Civ V (minimal requirements [1]) on this laptop, but can't a single web-widget? This is tragic quality.
Constructive or not, looks like author didnt test it on every browser on a lower-performance hardware like 10year old CPU, eg. maybe i3. If I use this widget in my development and we give a product with this widget to customer who runs IE11 or EDGE on i3 from 2012, it will be my problem to fix it. I will complain to the developer, we all waste time and resources.
If developer of a thing wants to show us something they're proud of. Test it, benchmark it, show it. Never let us, users benchmark and test your stuff, you will get blacklisted for that poor quality and performance software quickly.
I fixed the issue, was unrelated with the component itself, can you please have a look again and verify that it works fine? https://zzarcon.github.io/react-circle/
Incredibly poor attitude. This is free, open source software. You did not pay for this. If you found a bug and you don't want to wait for the developer to fix it, then fix it and make a PR.
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.
There's a difference between "hey man you should check this with a throttled CPU" and "I hope developer of this component never makes a single webpage."
Still condescending if you ask me. Be constructive, his work is free and nobody forces you to use it. If your goal was to help the guy...you failed; "that had to be a challenge, but you did it".
Without knowing anything about the implementation, I'd guess this is not a case of using CPU/GPU a lot and causing a subsequent slowdown, but a case of a misplaced/misconfigured debounce function.
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?
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.
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.
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.
Use a canvas and render the component directly? You’re rendering a circular progress bar, that should be easily doable in microseconds if not nanoseconds. There’s no need to use the overly bloated DOM for everything.
I suggest taking a look at Android’s views or even Flutter.
Yeah, more than likely the only problematic part is the transition animation. The main problem was another component breaking the performance in the examples page, not the component itself. Should be fixed now :)
Congrats! Very nice looking. CC: consider adding a title (or desc?) element for accessibility. Although you have a lot of the info in text, I find adding a title/desc element to all svgs is a good habit.
Which can also be used intentionally as a feature.
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.
I was working on the same exact thing in the latest days. In my opinion the transition stroke-dashoffset is too performance hungry to be really usable. I ended up throwing away my svg implementation to redo it in canvas.
If you're going stateful to handle timers remember to use requestAnimationFrame
55 comments
[ 3.6 ms ] story [ 134 ms ] threadThe difficult part is usually to determine how much time is still needed for a computation.
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..
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.
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
https://gfycat.com/NimbleMintyBinturong
That's on my laptop with i5, 4 cores. I can play smoothly on this L4D2, TF2, CivV... but not this reactive circular-progress bar.
I play on this laptop Civ V (minimal requirements [1]) on this laptop, but can't a single web-widget? This is tragic quality.
Constructive or not, looks like author didnt test it on every browser on a lower-performance hardware like 10year old CPU, eg. maybe i3. If I use this widget in my development and we give a product with this widget to customer who runs IE11 or EDGE on i3 from 2012, it will be my problem to fix it. I will complain to the developer, we all waste time and resources.
If developer of a thing wants to show us something they're proud of. Test it, benchmark it, show it. Never let us, users benchmark and test your stuff, you will get blacklisted for that poor quality and performance software quickly.
[1] https://support.2k.com/hc/en-us/articles/201332873-Civilizat...
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.
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?
let me know if you still experience that issue
https://gfycat.com/TerribleWeeArmadillo
(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.
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.
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.
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.
If you're going stateful to handle timers remember to use requestAnimationFrame