Cocos2d-x game power consumption has been a headache, a simple three elimination game, play for a while the phone is hot, more depressing is the battery consumption is very fast, basically, the battery can be used up in two hours. Recently saw a post, a foreigner with cocos2d-x transplanted on Android 2048 this game, everything went well, except the phone will be hot. It seems that this is indeed an unpleasant problem.
I have worked on a windows desktop system before. I know that on windows, the screen will not be repainted in full screen at every frame, but will provide a WM_PAINT message through which the windows GPU driver sends a message, you can obtain the area to be repainted to reduce the GPU load. But I checked the opengl document and it seems that it does not support area re-painting (this is the core technology of MS Windows ). The bottom layer of the cocos2d-x is implemented with opengl, and it cannot be optimized through area re-painting.
Is there any other way? After studying the engine code, I found that the main rendering process of the engine is very simple, that is, to repaint the screen with a fixed 60 FPS, even a static screen, is also a constant 60fps. In fact, it can be optimized here. Don't refresh the completely static screen! I modified the code and did some tests to make it possible: Add a dirty re-painting mark to the ctor class, check before each frame is drawn, and skip this frame if it is not set up.
So when do we need to set a re-painting mark? That is, when the image on the screen changes (as if it is nonsense ...). The cocos2d-x uses two methods to produce an animation, one is action (such as Move), the other is event (such as Touch); the standard action is managed through ActionManager, therefore, you only need to set re-painting in the update () function of ActionManager. The event is managed in a unified manner through eventDispatcher, and can also be set in this class. Code will not post, you can see this PR: https://github.com/cocos2d/cocos2d-x/pull/6178
However, if you do not update the image through action or event, such as directly setting the node location or customizing the schedule callback function, you need to set the re-painting flag by yourself.
Ricardo is also in favor of this function, and it is recommended to implement it in the node visit function, so that the re-painting mark will be completely transparent to engine users, however, this feature will be officially released only when it reaches 3.1. If you are interested, you can merge this PR and try it first.
I tested it myself. After optimization, I ran the testcpp main interface for half an hour, and the phone was cold and cold :)