Sprite is flickering while moving

[Aleksey]

Hi, i am newbie in Pixi.js and HTML5 game dev, and faced with unpleasant behaviour of Pixi.js on my first try.

When i create simple stage with one sprite and try to move this sprite over x axis i see flickering.

I made example of this: http://jsfiddle.net/gzg4xj6g/

I test this code using Linux, Windows, Mac  Chrome and Mozilla and flickering of card is observed on all this platforms and browsers.

I tried to reduce coordinates update frequency limiting updates on 30 fps and etc, but result was the same.

 

Could you please tell me what i am doing wrong?

How to make card  movement animation fast but smooth i.e. get rid of this annoying flickering?

Or this behaviour is common for Pixi.js?

 

Honestly i tried to create this simple scene using pure JS, jQuery animation and CSS animation and results were similar

 

 

 

[rich]

If I slow your movement down (to 1 instead of 15) then it moves as smooth as butter, no flickering at all. If I leave it at 15 then it looks like a bit of a mess because you've got an extremely high contrast image against a dark background which is moving at 15 pixels per frame, which is incredibly high. In other words, it's going to look a little odd no matter how you do it at that speed, with those assets.

[Aleksey]

First of all, thank you for so quick answer.

Indeed my assets is absolutely not from real world app. But if i try to use white background (http://jsfiddle.net/gzg4xj6g/2/) picture does not changes for me.

If i reduce dx value to 1 px all is looking good, but according to measurements renderFunction is called once per 16ms ~ 60fps,  hence card is moving with aprox. speed 62 px per second, and for canvas that has width 821px  movement will takes 13 seconds. Such low speed  of card movement is inacceptable for my app. 

Is there a different way to achieve more high velocity for sprite movement?

[rich]

When I tested it, it was running at "dx = 15". Which is sprite.x += dx every frame. On my desktop that's 60 times per second. So in the course of 1 second it has moved 900 pixels at 15 pixel intervals. This is a substantial distance to travel in a very short period of time, and will never look "smooth" because of the gaps between frames.

 

The high contrast imagery just exaggerated it.

 

Add to that the way lots of browsers (Chrome especially) are totally screwed when it comes to vsync and you've got a perfect storm imho.

[msha]

Surprisingly, it's smoothest in IE 11. Chrome does the worst.

 

 

Is there a different way to achieve more high velocity for sprite movement?

 

Try using some easing function, cubic ease-in, ease-out, etc. Jerkiness will be less noticeable then, I guess.

[Aleksey]

Looks like issue was caused by my PC configuration - i use 2 monitors.

When i switched to 1 monitor output negative effect was significantly less noticeable.

Most interesting that mobile Chrome demonstrated absolutely absence of jerkiness effect.

Thank you all for support.

 

P.S. 

I still could not make a decision what will be best for my app:  jQuery Animation or Pixi.js?

Could some one please provide some arguments for Pixi.js?

[Aleksey]

Looks like now i can answer my question by my self

 

I made a little benchmark for Pixi.js and plain JS animation(requestAnimationFrame) , and here is results:

 

For Pixi.js i use 100 sprites that share same texture and moving randomly to one of the screen corner.

Chrome profile show > 88% idle time on my LG G2

 

For plain JS i use 100 div that shares same background(same class) and moving randomly to one of the screen corner(with jQuery.css).

Chrome profile show < 43% idle time in best case.

 

I think this thread could be closed, thank you all.

[msha]

Are you animating top and left properties? Try with transform: translate and without jQuery(jQuery does not use RequestAnimationFrame AFAIK).

[Aleksey]

Are you animating top and left properties? Try with transform: translate and without jQuery(jQuery does not use RequestAnimationFrame AFAIK).

Yes i just use:  div.css('left', x | 0).css('top',  y | 0);

And i did not use jQuery animate for this benchmark, i made simple function that change div position based on requestAnimationFrame and limited to 30fps for both cases.

 

I completely forgot about transform property, let me check how fast this method is.

[Aleksey]

Hmm most interesting, that transform does not show any advantages over div.css('left', x | 0).css('top',  y | 0); method.

Unfortunately, i cannot profile this with mobile device now, but  on my PC profile show > 80% idle for both methods.

[msha]

http://www.goodboydigital.com/to-dom-or-not-to-dom/

DOM is much slower according to this.

Would be interesting to test if using css transitions or animations would be better than moving them manually....

[JDW]

CSS transition will be hardware accelerated if our hardware allows it. That should be why your mobile chrome is perfect while your desktop shows some flickering. I guess your chrome on desktop computer can't properly use hardware acceleration.

Anyway, if you are looking for an average scale of animation speed : DOM < CSS transition (accelerated) <= 2DCanvas < Webgl. But please note that both 2DCanvas and Webgl will use more memory.