Html Canvas 1600x1200 Screen Tearing

I've seen a couple of questions asking about this, but they're all over three years old and usually end by saying theres not much of a way around it yet, so im wondering if anythin

Solution 1:

Are you using requestAnimationFrame (RAF)? RAF will v-sync but setTimeout/setInterval will not.

http://msdn.microsoft.com/library/windows/apps/hh920765

Also, since 30fps is adequate for your users to see smooth motion, how about splitting your 60fps into 2 alternating parts:

• "calculate/update" during one frame (no drawing)

• and then do all the drawing in the next frame.

And, get to know Chrome's Timeline tool. This great little tool lets you analyze your code to discover where your code is taking the most time. Then refactor that part of your code for high performance.

[ Addition: More useful details about requestAnimationFrame ]

Canvas does not paint directly to the display screen. Instead, canvas "renders" to a temporary offscreen buffer. “Rendering” means the process of executing canvas commands to draw on the offscreen buffer. This offscreen buffer will be quickly drawn to the actual display screen when the next screen refresh occurs.

Tearing occurs when the offscreen rendering process is only partially complete when the offscreen buffer is drawn on the actual display screen during refresh.

setInterval does not attempt to coordinate rendering with screen refresh. So, using setInterval to control animation frames will occasionally produce tearing .

requestAnimationFrame (RAF) attempts to fix tearing by generating frames only between screen refreshes (a process called vertical synching). The typical display refreshes about 60 times per second (that’s every 16 milliseconds).

With requestAnimationFrame (RAF):

• If the current frame is not fully rendered before the next refresh,

• RAF will delay the painting of the current frame until the next screen refresh.

• This delay reduces tearing.

So for you, RAF will likely help your tearing problem, but it also introduces another problem.

You must decide how to handle your physics processing:

• Keep it in a separate process—like setInterval.
• Move it into requestAnimationFrame.
• Move it into web-workers (the work is done on a background thread separate from the UI thread).

Keep physics in a separate setInterval.

This is a bit like riding 2 trains with 1 leg on each—very difficult! You must be sure that all aspects of the physics are always in a valid state because you never know when RAF will read the physics to do rendering. You will probably have to create a “buffer” of your physics variables so they always are in a valid state.

Move physics into RAF:

If you can both calculate physics and render within the 16ms between refreshes, this solution is ideal. If not, your frame may be delayed until the next refresh cycle. This results in 30fps which is not terrible since the eye still perceives lucid motion at 30fps. Worst case is that the delay sometimes occurs and sometimes not—then your animation may appear jerky. So the key here is to spread the calculations as evenly as possible between refresh cycles.

Move physics into web workers

Javascript is single-threaded. Both the UI and calculations must run on this single thread. But you can use web workers which run physics on a separate thread. This frees up the UI thread to concentrate on rendering and painting. But you must coordinate the background physics with the foreground UI.

Good luck with your game :)