cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: requestAnimationFrame Re: Google Team's Task Backlog: Android
Date Mon, 29 Jul 2013 18:03:21 GMT
My understand was that: events fire faster than UI paints, and general good
design is to coalesce and update UI once on RAF.  In this case, the events
came from native and were sent across the bridge, which meant the while the
app js could do the coalescing, doing it on the native side meant huge perf
boost (the bridge overhead itself was huge).

Any automatic throttling of exec calls on RAF likely wouldn't do nearly as
well as plugin specific changes to just not spam in the first place.

BUT! I do think that Andrew Trice needed to implement sending the RAF tick
over to native so that the plugin knew when to send over the event.  This
part could potentially be added by us to the bridge (or perhaps as a core
plugin?) so that its easier for plugins to take advantage of (say, for
perhaps accelerometer / geolocation / etc), and so we only need to synch
RAF once, and not duplicate the overhead inside multiple plugins.

-Michal


On Mon, Jul 29, 2013 at 10:33 AM, Andrew Grieve <agrieve@chromium.org>wrote:

> I'm not sure the exact details, but it was something Andrew Trice said he
> did in his PGD talk. I may not have understood correctly. I think the issue
> might be that our bridge doesn't have any throttling built in.
>
>
> On Mon, Jul 29, 2013 at 12:01 AM, Jesse MacFadyen
> <purplecabbage@gmail.com>wrote:
>
> > Hopefully the subject change started a new thread.
> >
> > Why would you use reqAnimFrame for exec? Native calls have nothing to
> > do with repaints, so this makes no sense to me...
> >
> > Sent from my iPhone
> >
> > > On Jul 25, 2013, at 10:49 AM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > >
> > > We've done some planning around what we'd like to get done over the
> next
> > > quarter, and so I thought I'd share.
> > >
> > >
> > > This isn't to say that we'll be going and doing these things without
> > > further discussion or proper JIRA issues. It also doesn't mean we will
> be
> > > solely focused on this list, nor that we'll actually end up completing
> > > everything on the list. Just that we *currently* think that these
> things
> > > should get done.
> > >
> > >
> > >
> > > cordova-android:
> > >
> > > - Change plugins to have distinct package names
> > >
> > > - Look at using requestAnimationFrame to throttle exec bridge (advice
> > from
> > > a PGD talk)
> > >
> > > - Move JSONUtils out of core (to minimize API surface) (was added by
> our
> > > intern a while ago)
> > >
> > > - Move FileHelpers out of core (Most functionality now lives in
> > > CordovaResourceApi)
> > >
> > > - Move ExifHelpers out of core and into Camera (used only by Camera)
> > >
> > > - Extract Database plugin out of core (and into... cordova-labs?
> > > cordova-android?)
> > >
> > > - Change CordovaWebview constructors to accept a CordovaInterface
> instead
> > > of a Context (get the Context from the getActivity() of
> CordovaInterface)
> > >
> > > - Make private (or package-private) any api that is likely unused by
> > third
> > > party plugins
> > >
> > > - (CB-3900) Have PluginResult that gets populated lazily - at the time
> of
> > > being sent over the bridge.
> > >
> > > - Use source instead of .jar
> > >
> > >    - Easier to debug, faster "project create", consistent with how
> > plugins
> > > work
> > >
> > > - Extract splashscreen logic out of core
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message