(forgot to cc dev.platform in my reply) On Sat, Feb 28, 2015 at 3:47 AM, Paul Rouget <p...@mozilla.com> wrote: >> So in order to implement the behaviour you're looking for we would >> definitely need to make some changes in gecko. > > How much work is that? Is it just a matter of "piping" things together > to expose an JS method to privileged code? > >> What if, for example, you just used a CSS transform animation to bring down >> the URL bar? > > I wish we could just do that. But there are 2 problems with this > approach: 1) position:fixed elements on the page would not be pushed > down, and will be covered by the navigation bar. 2) we want the > navigation bar to hide again on scroll. And the animation needs to be > scroll-based (scroll snapping behavior). So that means, eventually, we > need to scroll the content to make it possible to scroll down again to > hide the bar. And we're back to square one. > > > On Fri, Feb 27, 2015 at 8:09 PM, Kartikaya Gupta <kgu...@mozilla.com> wrote: >> Ah yeah I didn't realize (I should have though) that the scrollTo >> calls will be happening in separate processes and the IPC lag will >> make it hard to synchronize them. That makes it much more tricky. >> >> Presumably you want two requirements: (1) to kick off this process >> from the parent process main thread and (2) to have it never block on >> the child process' main thread. If (2) is not satisfied then basically >> you're allowing arbitrary web content to block or delay the behaviour, >> which I presume is highly undesirable. Since you need to move at the >> very least the URL bar layer and the fixed-pos layer, this effectively >> means that you want to be able to manipulate the child process layers >> directly in the parent process, and there's no gecko machinery that >> currently allows this. So in order to implement the behaviour you're >> looking for we would definitely need to make some changes in gecko. >> >> However, there is a different approach you might be able to take if it >> satisfies your UX requirements. What if, for example, you just used a >> CSS transform animation to bring down the URL bar? It would hide the >> fixed-position layer, but depending on when you want this that might >> be ok. Particularly if you undid the CSS transform as soon as the user >> started scrolling. >> >> Conceptually it seems to me like wanting the behaviour of showing the >> URL bar while you're partway down the page doesn't fit with the basic >> model of having the document sit inside a nested scrollable container. >> Because this behaviour is "out of band" I don't think it makes sense >> to use an "out of band" mechanism (i.e. not scroll offsets) to >> implement it. That's why using CSS transforms to accomplish this seems >> to make sense to me. >> >> >> On Fri, Feb 27, 2015 at 5: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
-- Paul _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
