My gut feeling is that if you rendered the different stages of the animation into multiple images using canvas and just toggled their visibility, you could get better performance.
CPU time measurements, especially percentages, get very fuzzy when the CPU isn't loaded.
I'm on Chromium 12 on a Fedora 15 box. Top reports ~25% (on a dual core Arrandale, so that's about 1/8th the available CPU time), but checking the clocks more carefully shows that they're spending half their time in sleep states and never moving from the 1.2GHz base speed (this model turbos at 2.9GHz). So my envelope tells me this is about 4-5% usage vs. a fully loaded system.
Interesting replies. 0% on IE 9 and Chrome 13, and 15% on firefox 5 (which translates to 60% of a core). Running Win 7 x64.
Aaaaaand... just upgraded to Firefox 6. 0%. Rather fickle piece of javascript, eh?
A spinner generated from http://www.ajaxload.info/ is 673 bytes. The minified javascript from this is ~3K. I suppose the trade off is features and flexibility, but I don't find myself needing much out of my ajax spinners.
The w3schools site provides an excellent overview of the new input types and there browser support in this case.
So maybe next time please don't link to w3fools (stupid site imho) but provide a better link.
Agreed... This is fine as an exercise but I don't want to maintain code for every minor component; I'd rather go with an image even if it were bigger than 3K.
I think the possibility of dynamically changing the speed of the spinner is interesting. If your spinner was representing a file upload, for example, you could conceivably adjust the speed based on the current upload rate.
I completely agree with you, but the user might have been trained by his iPhone to relate the speed of the spinner to the data transfer speed. (The spinner in the status bar of the iPhone indicating network activity has a different speed when you're on EDGE or GPRS versus when you're on 3G).
You raise an interesting point. That throbber does have (exactly) two speeds — but if you are experiencing EDGE-speed transfer rates over 3G for some reason (low connectivity), it still spins at the normal (3G) speed. So it’s not quite the same as what’s being suggested here, as I understand it (a variable speed throbber tied to current transfer rates). Certainly an intriguing design decision though.
I have to imagine the slow speed of the EDGE throbber is saying, “Expect this to take awhile. Look, I take 6 seconds to even spin around once…”
Thus if we were to take the concept to the Web, it might make more sense to tie rate of revolution not to speed, but rather to expected time to complete (based on speed and file size) such that we expect the spinner to make exactly (say) 15 revolutions before the upload completes (with a min and max cap on revolution speed, of course).
I still maintain that if we know this much information, though, we ought to just show a progress bar and optionally text as well.
Doesn't that defeat the purpose, though? Progress indicators are designed to make you think things are going faster than they are. If you want to display accurate information, why not just display it?
"Progress indicators are designed to make you think things are going faster than they are."
Says who? I think progress indicators are intended to communicate more-granular details about the true progress towards some goal ... hence their name.
That doesn't even pass the sniff test. What progress indicator can you come up with that provides more or better information in the same space than "95% loaded" or "10.7/75MB of files copied"? Why do you think progress bars so frequently do not include that straightforward information?
It's a scam. It's a nice scam, of course, since it makes computers seem faster, and that's most of what really matters, but a scam nonetheless.
It's not about better information, it's about speed of information. You can look at a progress bar and instantly gauge the progress of your task. "10.7/75MB copied" is more precise, but of less intrinsic value--I have to calculate in my head where the halfway point is. To get a percentage in my head out of those numbers is even harder.
Try it. Half of 75 is about 37, so I'm a little under a third of the way to the halfway point. I'll be a quarter done at ~19. Takes about two seconds. Even faster for a computer, of course.
Now do that with a progress bar. You can't. What do you do, hold a piece of paper under the bar and fold it in half? Then guess whether the bar is measuring estimated time to completion, percent of data transferred, or percent of files transferred?
You can ballpark it at a glance, sure. It's obviously under a quarter done. Obviously over a tenth. Is it under a fifth? Maybe. We're just not good at judging those things. And progress animations are deliberately designed to make it even harder.
And don't get me wrong-- it's nice to be able to ballpark it at a glance. It reassures me that it's moving at all. It gives me some idea of how much longer it will take. It makes it seem like it's going faster. That's what I'm saying.
Progress bars are what you make them. There are many accurate progress bars in use(Windows 7 file copy, YouTube progress bar). They are not inherently designed to mislead.
I think buffer indicators are a different beast from progress bars-- the timeline is a UI element, and the buffer indicator shows something concrete relating to it.
But I don't think I've said progress bars are bad. They're useful! It's just the idea of "maybe we can make progress indicators more accurate" that's ridiculous.
jsdalton was merely proposing ways this demo could be enhanced by linking it's behavior to a source of data. You're the one going all over the place with your disdain for progress bars, suggesting they are inaccurate & "a scam", then taking it back or questioning what a progress bar is... I am really not sure how a progress bar for a video buffer is all that different from a progress bar for a file transfer.
No idea where you see disdain, and I certainly haven't taken anything back. Progress bars are inaccurate, in the sense that they're simply not a good way to convey accurate information about task completion to a human user. Them's just facts.
But that's not bad. I said it was a nice scam. Sometimes it's good to be fooled. Putting a minigame during the load screen doesn't make the real game load any faster, but it makes the time seem to pass faster, and that's nice. Doesn't make it not fooling.
As for streaming video, as I said already, a video buffer indicator is tied to a UI element in the timeline. It tells me where I can scrub to in the timeline and have it play video immediately without buffering. That's useful.
It's not useful as a progress indicator, for telling me how much longer I need to wait to watch the video-- because my computer is way, way better at doing that math than I am. I would much rather have a simple indicator that tells me, given my current download speed, whether I will have to wait for buffering before it finishes playing, and if so, how long I have to wait until that is not the case. In fairness, you can get a decent idea of that based on whether or not the buffer indicator is advancing away from the playhead, which is another detail that distinguishes a streaming buffer from other sorts of progress indicators.
I use indicators whenever I need to provide feedback for viewers waiting for some action to take place so they don't think that something froze/disconnected/isn't responding.
Are there any GIF loader generators that have all this options (speed, sizes, color) available? Could be good to use this as a preview, and then generate the final GIF.
This is cool just for fun, but practically there are sites like http://ajaxload.info/ that generate spinners for you, if you don't know how to do it yourself
I tried them and they produced poor quality. They couldn't even get the white background correct! I suppose their #1 ranking on Google is making them complacent.
http://www.loadinfo.net/ is much better presented and actually respects the color values you type in! (And no, I don't have any relationship with them.)
I accidentally upvoted you (trying to view your profile, I dont have downvote privileges). The CPU use of just about any GIF spinner is trivial compared to this, even in the browser this runs best in. Sure its a solid enough concept, but not something that'd you actually use in practice yet.
I actually agree that a JS spinner probably uses too much CPU to be justify its use, but I seriously doubt it would have that much effect on the battery.
EDIT:
It also seems the actual spinning is done with CSS, not JS
Tested it on my iPhone 3gs - after some scrolling around and zooming (trying to reach the controls) the spinner "locked up" - it's no longer spinning, every bar is simply pulsing together in time, like a luminescent jellyfish.
I wonder if this could happen in a regular browser, too?
It was noted in this thread that this consumes a relatively large amount of resources, and it was suggested that flipping through PNG frames would be less CPU-intensive.
I have a hunch that’s correct, but don’t know.
I do however have an unanswered question on Stack Overflow seeking, ideally, a generator of JavaScript + PNG throbbers. First one to make ajaxload.info with PNG sprites and/or Canvas generation in supported browsers wins! (No need for most of the hideous ajaxload designs though.) http://stackoverflow.com/questions/6937149/best-practice-too...
The only reason to use this is for scalable throbbers, and since you're only going to configure it once, it'd be much easier and more compact to just use a generated SVG+SMIL instead.
Read through quickly at first and got mislead by 'target' assuming that anything passed as a target will start spinning and tried to spin an image :), which of course is not the case. Nice effort though.
This would be perfect for canvas games. It means that image.gif doesn't have to load, which typically requires initializing a new Image() and attaching an onLoad function. This simplifies all that.
