On Mon, Sep 1, 2014 at 4:39 AM, Thinker K.F. Li <[email protected]> wrote: > Jonas Sicking <[email protected]> writes: > >> On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto <[email protected]> > > wrote: >>> >>> Comments are *very* welcome. >> >> > ...... skip ...... > >> >> Third, when I have pondered this stuff in the past, it seemed to me >> like a lot of the complexity comes from the fact that the system app >> generally had most of the information about which app is most >> important. However gecko made all the decisions. And the only way that >> the system app could influence gecko was through setting various >> properties through the browser API which only affected LMK levels CPU >> priorities in indirect and complex ways. > > I am afraid it would be inefficient for the longer response time. For > example, we would prefer to give the dialer a highest priority for ringing. > So, we would try to lower the priority of the music player process at first > monent if there is. The path of ring from RIL to system app is far too > long/slow for some stressed circumstances. One solution is to break layers > and pass events; like ring, to the system app through a shortcut, then we > will expose a lot implementation details to the system app.
Where is the extra overhead coming from? Is it because we have to go through the main thread in the parent process? Or is it because the system app is doing a lot of JS processing before it actually creates an <iframe mozbrowser> element? Or is it because we run a lot of gecko code between the <iframe mozbrowser> element has been created and we actually start talking to the pre-forked app process? Or is it something else? / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
