With web i usually just use the native scroll mechanisms. They are fast, reliable and there is no coding involved.
But, while working more and more in Unity, i have discovered that the available plugins for scroll, even the big ones such as Unity.UI or NGUI are simply awful. I have asked around, and found out that it is like that in most platforms. The physics is plain bad.
I did a bunch of research and i have tried a few solutions, from NGUI scrollView, to web iScroll.js and so on. I have found no solution as perfect as the original Apple's PastryKit. Now, PastryKit is old, deprecated, has no API and as hard to read as hieroglyphs.
But what is important is that while making it, they have managed to exactly recreate the iOS kinetic scroll physics behavior.
I am not trying to implement PastryKit , i am trying to find out how it works. I am trying to understand and replicate.
I am trying to find out the easings/formulas they use and logical conditions they use them in. Apple has a crazy way of writing confusing JS, so even tho i am a full stack developer, i am having a hard time tracing everything down. And i figured few brains is better than one, so lets see, does anyone understand this file? :D
https://github.com/jimeh/PastryKit/blob/master/mobile/dist/PastryKit.js
IN SHORT (so there are no misunderstandings): I am trying to extract a set of physics rules from this file, which i can use as guidelines in order to write my own implementation of scroll on any platform i choose. :)
for example: 'normal' scroll is defined by {>300ms && >10px}, apple uses the following bezier curve when easing the animation of slowdown. cubic-bezier.com/#.25,.46,.1,.94
UPDATE: We solved this a while ago. We discovered how Apple does it's momentum.
https://medium.com/homullus/recreating-native-ios-scroll-and-momentum-2906d0d711ad
After many hours of dissecting the algorithm, we concluded that Apple is in fact using magic numbers. And the magic number is: (drumroll) momentum * 0.95.
Basically, while the touch lasts, apple lets you move the screen 1:1.
On touch end Apple would get momentum by dividing number of pixels that the user had swiped, and time that the user has swiped for. If the number of pixels was less than 10 or time was less than 0.5, momentum would be clamped to zero.
Anyways, once the momentum (speed) was known to us, they would multiply it by 0.95 in every frame, and then move the screen by that much.
So idiotically simple and elegant, that it hurts. :)
Related
How can I control the rendering loop frame rate in KineticJS? The docs for Kinetic.Animation show a frame rate being passed to the render callback, and Kinetic.Tween seems to have no frame rate logic, but I don't see anyway to force, say, a 30fps when 60fps is possible.
Loads of context for the curious follows, but the question is that simple. If anyone reads on, other advice is welcome. If you already know the answer, don't waste your time reading on!
I'm developing a music app that combines some DOM-based GUI controls (current iteration using jQuery Mobile) and Canvas-based GUI controls (using KineticJS). The latter involve some animation. Because the animated elements are triggered by music playback, I'm using Kinetic.Tween to avoid the complexity of remembering how long a given note has been playing (which Kinetic.Animation would require doing).
This approach works great at 60fps in Chrome (on a fast machine) but is just slow enough on iOS 6.1 Safari (iPad 2) that manipulating controls while animations are happening gets a little janky. I'm not using WebGL (unless KineticJS or Chrome does this by default for canvas?), and that's not an option when I package for native UIWebView.
As I'm getting beyond prototype into wanting to make more committed tech decisions, I see the following options, in order of perceived goodness:
Figure out how to cap the frame rate. Because my animations heavily use alpha fades but do not involve motion, I believe I could get away with 20-30fps and look fine. Could also scale this up on faster devices.
Don't respond immediately to touch inputs, but add them to a queue which I poll at a constant interval and only use the freshest for things like touchmove. This has no impact on my non-interactive animated elements, but tackles the problem from the other direction, trying to reduce the load of user interaction. This would require making Kinetic controls static and manually tracking touch coordinates (not terrible effort if it actually helped).
Rewrite DOM-based GUI to canvas-based (KineticJS); rewrite WebAudio-based engine to HTML5 audio; leverage CocoonJS or Ejecta for GPU-acceleration. This means having to hand-code stuff like file choosers and nav menus and such (bad). Losing WebAudio is pretty serious as it eliminates features like DSP effects and very fine-grained, low-latency timing (which is working just fine on an iPad 2).
Rewrite the app to separate DOM based GUI and WebAudio from Canvas-based elements, leverage CocoonJS. I'm not sure if/how well this works out, but the fact that CocoonJS passes JavaScript code as strings between the 2 components makes me very skittish about how solid this idea is. It's probably doable, but best case I'm very tied to CocoonJS moving forwards. I don't like architecting this way, but maybe it's not as bad as it sounds?
Make animations less juicy. This is least good not because of its design impact but because, as it is, I'm only animating ~20 simple shapes at any time in my central view component, however they include transparency and span an area ~1000x300. Other components like sliders are similarly bare-bones. In other words, it's not very juicy right now.
Overcome severe allergy to Objective-C; forget about the browser, Android, and that other mobile OS. Have a fast app that performs natively and has shiny Apple-approved widgets. My biggest problem with this approach is not wanting to be stuck in Objective-C reality for years, skillset-wise. I just don't like it.
Buy an iPad 3 or later. Since I already am pretending Android doesn't exist (I don't have any devices to test), why not pretend no one still has iPad 2? I think this is passing the buck -- if I can get acceptable performance on iPad 2, I will feel confident about the app's performance as I add more features.
I may be overlooking options or otherwise naive about how to tackle this. Some would say what I'm trying to build is just silly. But it's working pretty well just not ready for prime time on the iPad 2.
Yes, you can control the Kinetic.Animation framerate
The Kinetic.Animation sends in a frame object which has a frame.time property.
That .time is a running timer that you can use to throttle your animation speed.
Here's an example that throttles the Kinetic.Animation: http://jsfiddle.net/m1erickson/Hn3cC/
var lastTime;
var frameDelay=1000;
var loop = new Kinetic.Animation(function(frame) {
var time = frame.time
if(!lastTime){lastTime=time;}
var elapsed = time-lastTime;
if(elapsed>=frameDelay){
// frameDelay has expired, so animate stuff now
// set lastTime for the next loop
lastTime=time;
}
}, layer);
loop.start();
Working from #markE's suggestions, I tried a few things and found a solution. It's ultimately not rocket science, but sharing what I figured out:
First, tried the hack of doubling Tween durations and targets, using a timer to stop them at 50%. This kinda sorta worked but was hard to get to look good and was pretty error prone in coding bogus targets like negative opacity or height or whatnot.
Second, having read the source to Tween and looked at docs again for Animation, decided I could locally use Animation instances instead of Tween instances, and allow the closure scope to hang onto the relevant note properties. Eventually got this working smoothly and finally realized a big Duh! which is that throttling the frame rate of several independently animating things does not in any way throttle the overall frame rate.
Lastly, decided to give my component a render() method that calls itself in a loop with requestAnimationFrame, exits immediately if called before my clamp time, and inside render() I update all objects in the Kinetic canvas and call layer.drawScene(). Because there is now only one animation, this drops frame rate to whatever I need and the app is fast on iPad 2 (looks exactly the same to my eyes too).
So Kinetic is still helping for its higher level canvas API, and so far my other control widgets are still easy code using Kinetic to handle user input and dragging, now performing much better as the big beast component is not eating up the CPU.
The short answer to my original question is that no, you can't lock the overall frame rate for very complex animations, but as Mark said, you can for anything that fits in a single Animation instance.
Note that I could have still used Animation without giving it a layer or explicitly calling any draw() methods, but since I'd still have to write all the logic to determine individual element's current visual state, there was no gain to doing this. What would be very useful would be if Tween could accept a parameter to not automatically render. This would simplify code like mine, as I could shorthand the animation on individual objects but still choose when to actually do the heavy lifting of rendering everything. Seeing how much this whole exercise gained in performance on the iPad 2, might be worth adding this option to the framework.
I'm doing voice recording in javascript, and storing the recording as an array of signed floats. What would I need to determine (and ultimately, adjust) pitch on the array? I've seen various algorithms for C++, but they don't seem to be very helpful in my situation. I even downloaded and tried this one to see if I could convert parts of it to javascript:
http://voicerecorder.codeplex.com/SourceControl/latest
But all that actually did was make the recording louder, regardless of the settings I chose.
I'm not going to try to provide an exhaustive answer here, but rather describe my own findings discovered on my journey of wrestling with similar issues in audio programming.
Pitch Detection
If you're sound is monophonic (as it sounds that is is based on your comment to jeff), I've implemented pitch detection using auto-correlation techniques, mostly because it's relatively simple compared to other pitch detection algorithms.
The idea, if you're unfamiliar, is as follows:
Slide a sample over itself (with a predetermined window size; in 1-sample increments)
At each step, calculate the absolute difference between the original wave and the slid window (hard to explain verbally).
as you slide the window, keep a record of the score calculated in (2)
when the wave correlates with itself, the score will hit a minimum, and the time-location of this minimum specifies the signals periodicity.
In my implementation, this was the only algorithm that worked well (when fed samples of my voice; I didn't try a variety of samples however).
That was a crude explanation of how autocorrelation works, and this article provides a very nice comparison of different pitch-detection algorithms:
https://ccrma.stanford.edu/~pdelac/154/m154paper.htm
Pitch Shifting
Of course, you could get really cheap pitch shifting by just resampling, but that sounds similar to a record being played too fast, which is not acceptable in many circumstances.
As far as pitch shifting goes, I haven't gotten that far yet in my implementation, but last I left off, I was looking at phase vocoders as a possible solution. What's hard is finding a decent explanation of how these algorithms work that provides some intuition on the reason why they work the way they do instead of just providing soley abstract mathmatical equations.
I have been spending about 7 hours today, trying to:
a) Create my own carousel using intensive javascript and CSS3 features (see this pastebin)
b) Setup and integrate the Roundabout plugin from FredHQ
c) Setup and integrate the Cloud Carousel plugin from Professor Cloud
Both third party solutions were tried because i failed in accomplishing what i wanted by myself. Unfortunately, both solutions do not work the way i would require them to. Both are amazing for displaying images, but i need to show more complex content, a heavily styled DIV with multiple encapsulated DIVs inside, PNGs with transparency, and so forth.
FredHQ's version did not work as it did not scale the content inside my DIVs. Not even the text was scaled, until i removed the font-size parameter, but that is something i need for a proper layout. Cloud's version works with images only.
I have hit a wall and i cannot seem to find any other solution. It seems the word "carousel" is used for slideshows and sliders, so i find hundreds of such solutions, but not one that works like i need it to.
What i need is decreasing opacity on further objects, while the center one is at full opacity. Also further objects should be scaled down by certain scale factors. It does not have to be 3D (not desired, even), but due to the scaling it would look 3d-like.
It does not have to be jQuery, although its probably a good idea if it is.
Does anybody know or can anyone point me to a proper solution?
Have you looked at monete(git), http://www.jacklmoore.com/monte? 184 line. Not sure you'll find something easier to dig into and make it work your way. Hundreds of solutions? So I'll take it you looked at the cycle plugin as well. That's probably one of the most mature and robust ones out there. You're asking for a lot in your question and these kind of question just wear people out after a while. That's all.
You probably won't find anything that fits your needs EXACTLY and you'll have to roll it yourself or hire someone. If you get something going and come back for specific help, you'll fair much better.
I have followed a couple of tutorials (http://www.adobe.com/devnet/html5/articles/javascript-motion-detection.html, http://www.html5rocks.com/en/tutorials/canvas/notearsgame/) and spliced the two together to create a game (https://github.com/gazzwi86/HTML5-Motion-Detection). While I have a few things to work out with the blending to improve the quality of the detection, I was wondering how I would go about detecting grabbing and swipe gestures, say for navigating a web page.
Could you point me in the direction of some examples or outline the principles so that I may try it myself.
I wouldn't go for it. It would require huge processing on client side to be quite good detection.
You can simply track moving objects(like hand) with some threshold(you can simply blur to get rid of noise). The background of user mostly will stay the same, so you can ignore it too.
Then convert image to black and white and try to have your moving object as one polygon.
What I would go to experiment after - set up a little neural network and train it myself by moving my hand.
Well that's just my 2 cents on how I would try to implement it. It would be really nice to hear from you later how did you do that and what the results are :)
I'm developing a site which has a flash background playing a small video loop scaled to fill the whole background. Over the top I have a number of HTML elements which are animated using javascript. The problem I am having is that (predominantly in FF, but also in others to a lesser degree) the flash seems to be causing my javascript animations to run rather jerky, and in some cases missing the animation altogether and just jumping to the end state.
Does anybody have any thoughts on how to make the 2 work together nicely?
Many thanks
Matt
You'll notice the same effect on BBC Iplayer - if you've played a few videos, then use the left and right scroller. The javascript animation is no longer smooth.
The is more noticeable in FF.
Chrome creates an entirely separate process for the flash, and therefore smoother, Safari is quite lightweight therefore smoother at times.
Bit of a bugger really - the only thing I can suggest is ensure your swf is optimised for CPU - if it contains lots of code, ensure you doing good memory management.
I had the same trouble once and I targeted FP10 - this offset a lot of visual work off the CPU (therefore the current process in the browser) and gave it to the GPU.
--
Aside from this, you're pretty much at the mercy of how powerful the clients machine is.
Additional for my answer above:
Thanks Glycerine. Do you think there would be any performance improvements if it was compressed into an older format? Or even just a SWF? There is no audio, so it's just an animated background really. – - Matt Brailsford
I think a newer format would be better - if you can do FP10, then again, you'll be able to utilise the user GPU, if your working in CS3, best to go for FP9.5.
Ensure your stage objects are cached for bitmap if your using large vectors
http://www.adobe.com/devnet/flash/articles/bitmap_caching_print.html
This ensures any heavy animation (even animation we regard as light) will run smoother because there turned into pixel data as opposed to complicated vector information. Its a small fix but it may work.
Try and target the AS3 engine as well. Even if your not using code. I keep saying it runs better than the as2, as1 engine with arguments from people but I'm sure you'll find your favourite camp.
If you have very large images scaled down, use a smaller form factor by photoshoping then to a smaller size. This will not only improve rendering speeds, but also swf file size.
Try those.