You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by SteveYTX <so...@gmail.com> on 2017/12/05 03:46:14 UTC
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
Re: Support HIGH-Frequency calls
Posted by "谷宝剑(剑白)" <ji...@alibaba-inc.com>.
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 <ji...@alibaba-inc.com>Time:2017 Dec 5 (Tue) 15:57To:dev <de...@weex.incubator.apache.org>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 <so...@gmail.com>发送时间：2017年12月5日(星期二) 11:51收件人：dev <de...@weex.incubator.apache.org>主 题：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
回复：Support HIGH-Frequency calls
Posted by "谷宝剑(剑白)" <ji...@alibaba-inc.com>.
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 <so...@gmail.com>发送时间：2017年12月5日(星期二) 11:51收件人：dev <de...@weex.incubator.apache.org>主 题：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