javascriptcore and v8 has poor performance on string concat. steven have an test, which show use json combine has amost 5 faster(101ms) then string concat(522ms). for improve g-canvas fps. three steps should be done. 1,use json combine instead of string concat for sending command2,new thread timer, maybe c++ timer is better3,support arraybuffer on android platform, avoid base64 encoding/decoding, which has an great performance improvement on ios platform. after the three step, g-canvas fps will be better.
------------------------------------------------------------------From:GU Baojian <[email protected]>Time:2017 Dec 5 (Tue) 15:57To:dev <[email protected]>Subject:回复：Support HIGH-Frequency calls yeah， we found the same problem, a different thread for hight frequency message is one soluation. please join my dingding jianbai.gbj for detail discussation ------------------------------------------------------------------发件人：SteveYTX <[email protected]>发送时间：2017年12月5日(星期二) 11:51收件人：dev <[email protected]>主 题：Support HIGH-Frequency calls Hi, Weex Dev Team I am developing a Canvas component based on Weex called G-Canvas. My design lists below: First, putting some OpenGL-capable views on the screen; Secondly, make a js framework which's APIs are as the same as HTML5 canvas and translate each API to my own protocol. Call it as "Drawing Command" or "Command" for short. Thirdly, pass drawing commands to a local rendering engine, parse each command and then draw each frame on screen. It works, but if the page's complicated, the FPS drops rapidly, especially on Android. The problem is Weex uses a Looper class for message management on Android, each message goes from Java to Native, and may go up in some situations (such as DOM update). This message channel is good enough for normal calls, but may not efficiently for high-frequency calls. so, if there are any high-frequency caller in a complicated page (such as a Canvas, 60 calls/second), race conditions comes out, the Looper's message queue may be blocked for some time. And iOS has the same problem. I think there are two ways to fix this: 1. If Multi-Context supported, use separated Looper and JS Thread for high-frequency calls component. 2. Make a different message channel for high-frequency calls component. Maybe a C++ timer and looper, to reduce Looper's pressure. Please let me know if you have any opinion. Any reply would be appreciated. Thanks. BR, Steven Xu
