According to https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame referring to requestAnimationFrame
The number of callbacks is usually 60 times per second, but will generally match the display refresh rate
I've not managed to find a system that runs at something other than 60fps. If the Javascript is busy, then I can certainly get it to be less, but only in that case.
Is there a system that, if there are enough resources, runs requestAnimationFrame at something other than 60fps?
Related
I am essentially trying to create a web app where one person can start a timer, and everyone else's timers (on different computers/phones) will start at the exact same time. I am currently using node.js and websockets. When the "master" timer hits start, the server uses websockets to tell all the devices to start. Since all the users should be on the same LAN, I thought I would not have to compensate for latency, but the timers are starting a few hundred milliseconds off of each other, and for my purposes, it is very noticeable. There isn't much delay between PCs, but mobile phones tend to be the most off of each other.
What would be the best way to get everything to start at the same exact time, within a margin of error of let's say, 50ms? I do not mind if the timers take a few extra seconds to start if the delay between them is within 50ms.
Send a timestamp to the clients when to start the timer.
Then the accuracy is tied to the accuracy of the system time.
If you can't ensure that the system time is accurate, another way would be to meassure latency and add it as an offset.
So I understand that in order to maintain the standard 60 frames per second when running animations in a web browser, we only get around 16ms per frame to perform any task we want to. The browser has to typically go through all the steps of the rendering pipeline to render each frame:
However, experts like Paul Lewis say that we realistically have only 10ms every frame to complete our tasks as browser has some 'overheads' and 'housekeeping' to do for every frame. I would like to know what these 'overheads' and 'housekeeping' tasks actually are?
"Overheads" vary per browser, and most don't occur on "every frame," but it all adds up, and overhead tasks performed either by your browser or by common client-side third-party code like Google Analytics also takes up valuable milliseconds. Common overhead tasks include:
Garbage collection
Listening for and handling often-repeated events such as scroll, mousemove, and some touch events (e.g. if you have analytics libs that generate heatmaps, that software may be tracking every mouse operation and touch operation)
Animations on your page (CSS ones or JavaScript-manages ones) which are "overhead" as far as the operation of your page are concerned
Third-party (or your own) code which does its thing only after certain conditions are met (e.g. lazy-loading of images, where images are loaded (and painted and composited) only when onscreen or close to being onscreen
Ads served by ad networks
Your own asynchronous code (triggered by setTimeout(), setInterval(), event-handlers, etc. etc. etc.) and that of any third-party libs which executes at some point, and when it does, eats into your 16ms (obviously there's a lot of overlap between this and the previous point)
Ad blockers and similar plugins (these run on a different thread, but interact with your thread, e.g., whenever DOM manipulation is necessary or any other cross-thread communication)
Loading of streaming media (which often consists of many network requests behind the scenes), which can include even relatively short, static videos
The overhead of running GIF animations or video (yours or UGC) - which is separate from the previous item, which concerns just the network interaction)
The repainting that needs to occur whenever the user scrolls or jumps to another part of your page (independent of any listeners for scroll, resize, etc.)
The potential complete redrawing of the DOM if some types of elements are added, removed, or resized, by you or by the user
Handling XHR or Iframe server responses or other data incoming from the network (like websockets traffic)
Tracking pixels (loading them, handling their demands of valuable JavaScript engine time); note that large sites often have a dozen or two tracking pixels of different types on them, and all it takes is one poorly written one to make huge demands on your browser's limited resources)
logic which attempts to anticipate what will happen next, and performing the optimizations involved
Heavy CPU usage by other applications running in your OS (or other pages running in other tabs in your browser) which take resources away from the JavaScript engine, rendering engine, etc.
Event-loop overhead - the JavaScript event loop is an elegant way of handling single-threaded code, but there's overhead involved in operating it
All of the above (a not-even-close-to-comprehensive list) would be considered "overhead" to whatever specific stuff you're trying to accomplish within 10ms or 16 ms or whatever.
Also note that some devices are just not capable of maintaining 60fps in-browser or anywhere; a slow CPU, lack of sufficient memory or persistent storace, etc., can slow all applications down, browsers included.
Maybe you're looking for something more specific, not sure - but I think I know the Paul Lewis thing you mention (where he talks about 10ms vs 16.66ms, etc.) and I'm not sure exactly what overhead he's talking about - but if, for example, you're trying to make one animation on a webpage run at 60fps, then all of the above would be "overhead" compared to your specific task of optimizing your animataion.
Hope this helps!
Creating a max-speed clock using setInterval only yields a maximum frequency of about 250Hz. For the project I'm working on I need a way faster clock. However, I do not want to run a 1000Hz clock in the main thread because of obvious reasons.
For now, the only plausible way I managed to reach a frequency of 1000Hz is by creating a second worker, running a while(true), sending a message to its "master" worker every time 1 millisecond has passed. This works, and the timer is accurate, however this is extremely resource-intensive. Just running this loop uses about 30% of my CPU.
Is there ANY other way of getting a fast clock to work? It can be as hacky as possible and abuse as many APIs as it needs, it just has to be A: Faster than a maximum setInterval speed & B: As resource-efficient as possible.
I am testing performance in my JavaScript application, a game using canvas. One problem I have is major fluctuations with FPS: going from 60 to 2 in ms.
As you can see, there are major spikes. It is not due to painting, scripting, rendering, or loading. I think it is because requestAnimationFrame doesn't assign a set FPS rate and it might be too flexible? Should I use setTimeout? Is it usually more reliable in these cases because it forces the application to run in only one set FPS rate?
Performance is always about specifics. Without more information on your app, (e.g. the specific code that renders your app ). It is hard to say how you should structure your code.
Generally, you should always use requestAnimationFrame. Especially for rendering.
Optionally store the delta time and multiply your animation attributes by that delta. This will create a smooth animation when the frame rate is not consistent.
I've also found random frame rate changes are usually related to garbage collection. Perhaps do some memory profiling to find if there are places you can avoid recreating objects each frame.
requestAnimationFrame is superior to setTimeout in nearly every way. It won't run as a background tab. It saves battery. It gives the browser more information about the type of app you are developing, and this lets the given browser make many safe performance increasing assumptions.
I highly recommend watching this talk by Nat Duca on browser performance.
What are some techniques or methods that could potentially reduce jank and/or improve paint times on browsers?
There isn't an exact answer for this but here are some high level techniques that may work for most situations
Reduce paint layers - Use the browser's dev tools to see how many layers your css or markup may produce. Changing or simplifying your css could potentially reduce better outcomes
Frame Budget - If the JavaScript inside your requestAnimationFrame callback takes longer than 16ms to run, you don't have any hope of producing a frame in time for v-sync
Utlize a virtual dom, or Web Workers API - If possible offload processing away from the client and Utilize web workers api for processing
Sources:
Jank Busting
Gone in 60 Frames Per Second