New issue
 Projects > js > Issues > Refactor #3284

Refactoring TMXLayer for better performance

Refactor #3284 [Closed]
ludingping 2013-11-27 02:24 . Updated over 10 years ago

Refactoring TMXLayer for better performance

pandamicro 2013-11-28 01:57

Dingping Lv wrote:

Refactoring TMXLayer for better performance

When we want to draw large image or cached canvas with canvas context’s drawImage function to a small canvas, FPS shapely drops down on Chrome.
Our TMXLayer object draws entier layer onto a cache canvas, and every frame, if the cache is not dirty, it will be posted to the scene directly, so this issue happens when user use a large TMX map.
This performance issue has been tested on Safari 7.0, Chrome 31.0.1650.57 and Firefox 19.0, and it occurs only on Chrome.
It’s related to a known Chrome issue 170021

pandamicro 2013-11-28 02:41

Possible solutions

I have tested two solutions but end up with no one suitable for Cocos2d-Html5, the essential idea was to limit the size of cache canvas.

  1. Grid cache
    First possible solution was to draw the cache into splited smaller canvas, in every frame update, all necessary sub cache will be draw to final canvas.

    * To support SpriteBatchNode functions, we must keep the large cache, in the same time uses smaller canvas for draw function, so memory use will be two times than origin version.

  2. Dynamic cache
    The dynamic cache is a canvas cache which is 2x bigger than the viewport, and it should be updated when viewport touches its border.

    * In the current version of Cocos2d-HTML5, cache dirty is transfered from child node to parent node. But the cache need to be updated even when parent scene moved. So we need a special break through for TMXLayer
    * The bigger problem is the node transform, the transform is applied from parent to children in ‘visit’ function, but when parent node has been transformed, in child node we must recalculate it’s transform related to world to detect if we need to update the cache.

pandamicro 2013-11-28 03:04


For this two solutions, each problem have its walkthrough, but it can be too heavy to use. Especially for the transform problem, matrix compute is very slow in javascript. Even more, these solutions can produce more bugs in the future in our system. Think of that the problem came with a Chrome bug, and it doesn’t happen for many users, I suggest that for now, we don’t use the solutions that I proposed. But if anyone found other solution more proper, it worth to look into it.

pandamicro 2013-11-28 08:05
  • % Done changed from 0 to 100

Finally, I applied grid cache solution, but I activate this solution only when TMXLayer larger than 10000000 pixels.

pandamicro 2013-11-29 14:03
  • Status changed from New to Closed

Applied in changeset commit:73ca736deb4357b17f98d5f97e1a3f0a508c4855.

Atom PDF

Start date:2013-11-27
Due date:
% Done:


Target version:v2.2.2