Propose to remove nsAString::AssignLiteral(const char (aStr)[N])
I think we should remove the method nsAString::AssignLiteral(const char (aStr)[N]) because its name is misleading. The method name AssignLiteral can easily make people at the callee side think it makes the string point to a piece of static data, which has no runtime penalty. But this is false. The fact is that, this method simply calls AssignASCII, which does a runtime conversion of the whole string, and stores the result dynamically. Hence I think we should remove this method. All callees should use either AssignLiteral(MOZ_UTF16(some string)), or, if don't want to bloat the binary, explicitly use AssignASCII(some string). (Maybe it will be eaiser to do so after we update the compiler requirement to VS2015, because since then, we can use u instead of MOZ_UTF16(). ) - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Jemalloc 3 is now on by default
On Tue, Jan 13, 2015 at 12:44:19PM +0900, Mike Hommey wrote: On Tue, Jan 13, 2015 at 10:13:34AM +0900, Mike Hommey wrote: Hi, I just landed bug 762449 on inbound, which enables Jemalloc 3 on the nightly channel. This puts us a step forward to removing mozjemalloc, our highly patched fork of jemalloc 0.9. More importantly, it will allow us to more closely work with upstream, by proposing patches that do apply there (which is not the case every time we do changes to mozjemalloc), or taking improvements from upstream (which, for some, we backported to mozjemalloc, with pain). Aaand as usual with such changes, it didn't stick. I just (finally) relanded this. It incurs a startup regression on Android, but it was decided we'd take it. There will be opportunities to improve things in the future. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Propose to remove nsAString::AssignLiteral(const char (aStr)[N])
On 3/1/15 5:04 PM, Xidorn Quan wrote: Hence I think we should remove this method. All callees should use either AssignLiteral(MOZ_UTF16(some string)), or, if don't want to bloat the binary, explicitly use AssignASCII(some string). The latter requires an strlen() that AssignLiteral optimizes out, right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Propose to remove nsAString::AssignLiteral(const char (aStr)[N])
On Mon, Mar 2, 2015 at 9:50 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/1/15 5:04 PM, Xidorn Quan wrote: Hence I think we should remove this method. All callees should use either AssignLiteral(MOZ_UTF16(some string)), or, if don't want to bloat the binary, explicitly use AssignASCII(some string). The latter requires an strlen() that AssignLiteral optimizes out, right? Yes, so we can add another overload to AssignASCII which does this optimization with less misleading. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: MouseEvent.offsetX/Y
On 02/28/2015 05:25 AM, Robert O'Callahan wrote: On Sat, Feb 28, 2015 at 8:30 AM, Jeff Muizelaar jmuizel...@mozilla.com wrote: On Fri, Feb 27, 2015 at 2:21 PM, Robert O'Callahan rob...@ocallahan.org wrote: Oh, another issue is that I've followed the spec and made offsetX/Y doubles, whereas Blink is integers, which introduces a small amount compat risk. IE also uses integers. Wouldn't it be better to change the spec to follow the existing browser's behaviour? In some ways, yes, although the extra accuracy given by doubles could be useful in practice. Haven't changes from integer to doubles caused issues in some cases. Boris might recall some examples. Rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Propose to remove nsAString::AssignLiteral(const char (aStr)[N])
On 03/02/2015 01:11 AM, Xidorn Quan wrote: On Mon, Mar 2, 2015 at 9:50 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/1/15 5:04 PM, Xidorn Quan wrote: Hence I think we should remove this method. All callees should use either AssignLiteral(MOZ_UTF16(some string)), or, if don't want to bloat the binary, explicitly use AssignASCII(some string). The latter requires an strlen() that AssignLiteral optimizes out, right? Yes, so we can add another overload to AssignASCII which does this optimization How would you do that? with less misleading. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Syncing 2 scrolling operations
(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
Re: Syncing 2 scrolling operations
(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
Re: Intent to ship: MouseEvent.offsetX/Y
On 2/27/15 7:25 PM, Robert O'Callahan wrote: On Sat, Feb 28, 2015 at 8:30 AM, Jeff Muizelaarjmuizel...@mozilla.com wrote: On Fri, Feb 27, 2015 at 2:21 PM, Robert O'Callahanrob...@ocallahan.org wrote: Oh, another issue is that I've followed the spec and made offsetX/Y doubles, whereas Blink is integers, which introduces a small amount compat risk. IE also uses integers. Wouldn't it be better to change the spec to follow the existing browser's behaviour? In some ways, yes, although the extra accuracy given by doubles could be useful in practice. Gecko's offsetX/Y could return doubles, for compatibility with the spec, that are always snapped to whole numbers, for compatibility with other browsers. Or Gecko could add random noise to the low bits of offsetX/Y so they are *never* whole numbers. Web developers would need to handle fuzzy results today, thus preparing for more precise results in the future. :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: MouseEvent.offsetX/Y
On 3/2/15 1:00 AM, Chris Peterson wrote: Gecko's offsetX/Y could return doubles, for compatibility with the spec, that are always snapped to whole numbers, for compatibility with other browsers. How, precisely, is this different from returning integers? Remember, this is JS we're talking about: there is only one Number type. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
