(forgot to cc dev.platform in my reply) On Fri, Feb 27, 2015 at 11:57 AM, Paul Rouget <p...@mozilla.com> wrote: > Hi Kats. Thanks for taking a look at this. > > On Thu, Feb 26, 2015 at 10:21 PM, <kgu...@mozilla.com> wrote: >> On Thursday, February 26, 2015 at 1:06:15 PM UTC-5, Paul Rouget wrote: >>> I need a pretty picture to explain my problem: >>> http://people.mozilla.org/~prouget/scrollIssue.png >> >> Thanks for the pretty picture! It makes it much easier to visualize the >> problem :) >> >>> I tried to scroll the parent and >>> the child process in opposite directions. It works, but it's choppy >>> and not at all seamless. >> >> This is pretty much what I would suggest, short of inventing some new API to >> do this. >> >>> Any idea how I could achieve this effect in a efficient way? I was >>> thinking about changing (and animating) the scroll position of the >>> content from the main process. Maybe finding a way to make >>> `scrollBy{behavior: 'smooth'}` for content and parent to be synced... I >>> don't know. Does that make sense? If so, how to build that? If not, >>> any alternative way to show this toolbar? >> >> Were you able to successfully get both things to scroll with >> behaviour:smooth? > > Yes. > >> Was that still choppy? > > At first yes, but with apzc and using rfa, it works much better now. > But not perfect. > >> Was it just that one animation started slightly before the other and so it >> resulted in a jittery effect? > > Exactly. Sometimes, the parent starts first, sometimes, the child does > (surprisingly). > Sometimes, it's perfectly synchronized. > > I'm on Mac, with APZC enabled. Multiprocess. B2G. > >> Or did the animations actually jank while in progress? > > The animation is very smooth. > >> I think if you trigger both scrolls inside a RAF and have both APZ-driven >> smooth scrolling > > How can you make sure they are triggered from the same RAF? If the IPC > communication delays the message a bit too much, it might miss the RFA > used by the parent process. > > And a thing i don't understand is that sometimes, the child process > scrolls first (I think). > >> vsync-triggered refresh driver it should be possible to get this working > > Do we support vsync on osx? > I set gfx.vsync.* to true. > >> because then it will be the same layers transaction that carries over both >> animations to the compositor, and they should proceed in sync. > > The 2 calls to scrollBy() are made from different processes. Even if > the 2 RFA are triggered from vsync, the child process still needs to > get back to the main process (where the compositor lives). Doesn't > this delay make it impossible to ensure that both animations will be > part of the same transaction? > >> I could be wrong though - CC'ing mason also who can provide more information >> about vsync-triggered refresh driver and whether it might help in this >> scenario. >> >> kats > > > Thank you! > > > -- Paul
-- Paul _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
