Obs 1080p 60fps Bit Rate Calc
Incul Möller
If I measure the time since the last frame in order to update my sprite positions correctly, I get a slight jitter in the movements. This is because the times are accurate to the millisecond, and 1/60s does not neatly fall on millisecond boundaries.
The main purpose of requestAnimationFrame is to sync updates to the monitor's refresh rate. This will require you to animate at the FPS of the monitor or a factor of it (ie. 60, 30, 15 FPS for a typical refresh rate @ 60 Hz).
If you want a more arbitrary FPS then there is no point using rAF as the frame rate will never match the monitor's update frequency anyways (just a frame here and there) which simply cannot give you a smooth animation (as with all frame re-timings) and you can might as well use setTimeout or setInterval instead.
The reason why we place setTimeout first (and why some place rAF first when a poly-fill is used) is that this will be more accurate as the setTimeout will queue an event immediately when the loop starts so that no matter how much time the remaining code will use (provided it doesn't exceed the timeout interval) the next call will be at the interval it represents (for pure rAF this is not essential as rAF will try to jump onto the next frame in any case).
These are all good ideas in theory, until you go deep. The problem is you can't throttle an RAF without de-synchronizing it, defeating it's very purpose for existing. So you let it run at full-speed, and update your data in a separate loop, or even a separate thread!
Use a separate setInterval for updating translation and rotation values, physics, collisions, etc. Keep those values in an object for each animated element. Assign the transform string to a variable in the object each setInterval 'frame'. Keep these objects in an array. Set your interval to your desired fps in ms: ms=(1000/fps). This keeps a steady clock that allows the same fps on any device, regardless of RAF speed. Do not assign the transforms to the elements here!
Use the RAF to update your transforms only, use only 3D transforms (even for 2d), and set css "will-change: transform;" on elements that will change. This keeps your transforms synced to the native refresh rate as much as possible, kicks in the GPU, and tells the browser where to concentrate most.
This keeps your updates to the data objects and transform strings synced to desired 'frame' rate in the SI, and the actual transform assignments in the RAF synced to GPU refresh rate. So the actual graphics updates are only in the RAF, but the changes to the data, and building the transform string are in the SI, thus no jankies but 'time' flows at desired frame-rate.
Same as method 1, but put the SI in web-worker. It'll run on a totally separate thread then, leaving the page to deal only with the RAF and UI. Pass the sprite array back and forth as a 'transferable object'. This is buko fast. It does not take time to clone or serialize, but it's not like passing by reference in that the reference from the other side is destroyed, so you will need to have both sides pass to the other side, and only update them when present, sort of like passing a note back and forth with your girlfriend in high-school.
This is the fastest way I know to animate elements via script. The two functions will be running as two separate programs, on two separate threads, taking advantage of multi-core CPU's in a way that a single js script does not. Multi-threaded javascript animation.
It's important to know that requestAnimationFrame depends on the users monitor refresh rate (vsync). So, relying on requestAnimationFrame for game speed for example will make it unplayable on 200Hz monitors if you're not using a separate timer mechanism in your simulation.
Run them separately. It's simple and not janky. In your setInterval, update your math and create a little CSS script in a string. With your RAF loop, only use that script to update the new coordinates of your elements. Don't do anything else in the RAF loop.
The RAF is tied inherently to the GPU. Whenever the script does not change (i.e. because the SI is running a gazillion times slower), Chromium-based browsers know they do not need to do anything, because there are no changes. So the on-the-fly script created each "frame", say 60 times per second, is still the same for say 1000 RAF GPU frames, but it knows nothing has changed, and the net result is it wastes no energy on this. If you check in DevTools, you will see your GPU frame-rate registers at the rate delineated by the setInterval.
For throttling FPS to any value, pls see jdmayfields answer.However, for a very quick and easy solution to halve your frame rate, you can simply do your computations only every 2nd frame by:
I found an ISP with a good up and down speeds, but it has a data cap which is 500 GB per month. I am wanting to stream soon, so I calculated how much data I will consume (streaming alone) in an hour. So here is my calculation.
I've noticed a handful of music videos that are shot in slow motion (my guess here is possibly 60fps?) and the performer is singing and yet the lips appear to be relatively in sync to the music. Now is this a case of simply shooting the performance like you normally would but just at a higher frame rate, or is there more to it that I'm missing ? Below are some examples the first one being the strongest.
I suspected something like that would have to happen. However I don't believe I can achieve a frame rate of 48fps with my fs700/odyssey 7Q combo, although I might be mistaken. How much should I speed the song if I want it to be in sync at 60fps?
The issue with higher frame rates is the more difficult for the performer to mime and maintain good lip sync. You should def give the performer time to practice. I've done this a couple of times and giving them a few days to get used to miming quickly will pay dividends.
We mostly shot at 25 fps - but did some 30fps to add weight to the falling bricks. We did a couple of takes at 50fps but the drummer really struggled with keeping up at that speed and couldn't do it for long periods. Any higher would have been too fast for sync on that track. A slower song might have allowed a higher frame rate. We were shooting on an EX1 which maxes out at 60fps so it wasn't an option anyway. But in our case it was about keeping the slowmo subtle rather then have it as an obvious effect. I used to work with a producer that was always keen on shooting at 27 to 28 fps for music videos.
If targeting a 2X slowmo, you can still shoot at 60 fps, or indeed at any other camera speed. What really matters is the rate at which the audio is played during the shoot. For 2X slowmo you will want to play the audio at 2X it's normal rate- regardless of camera rate. The performer mimes to the audio rate (singing 2X faster than normal). The camera can shoot at any rate it likes. But for a smooth result in the final deliverable you'll want to shoot at any rate that is equal to, or faster than 2X normal frame rate. So 60 fps is fine: it just means the superfluous frames you will have shot just get dropped during the final conform.
Why would you do that? If you want 2x Slowmo, you shoot at 48 or 50 fps. Shooting 60fps is just going to give you headaches in post. If you drop frames to get it into sync, your going to get motion judder. If you use time remapping your going to have long render times and the risk of motion artifacts such as warping.
If the performer is mining at 2x then you film at 2x. Possibly you could shoot at 4 x (to avoid artifacts) but what would be the point? Unless you wanted so ultra slowmo for non sync purpose. That said if your having non sync sections - its probably best to shoot at the highest possible frame-rate for maximum post flexibility.
I have the following doubt and one important question.
The datasheet of the 953 shows that the max sensor that you can connect is 2.3MP at 60fps or 4MP at 30fps. it means:
Video Throughput = 3.3Gbps = 2.3MP x 60 x Bits per pixel x 1.25 =>
Bits per pixel => 3328 / (2.3 x 60 x1.25 ) => 20 bits-per pixel, so, it's sounds reasonable, not sure or I misunderstood something?
My big question is about the maximum resolution. This is very important for us, because I already made some assumptions in the design, and we are moving toward prototypes at this moment for validation.
We are using the output of a FPGA MIPI CSI-2 D-PHY with 4 lanes below the max of the 832Gbps per line. The FPGA is like a "camera sensor" with a 3.6MP @ 60 fps with 10 bits per pixel.
so, Video Throughput = 3.6MP x 60 x 10 x 1.25 => 2.7Gbps
There is something that I'm not considering here? We are using a 3.6MP sensor at 60fps, but the datasheet mention max 2.3MP at 60fps or 4MP at 30fps.
Hope you can notice if we are missing something. It doesn't sound good that you mention in the datasheet that you can not handle a 4MP sensors at 60fps (it doesn't specify bit per pixel)
Thanks in advance. You feedback is really appreciated.