On Sat, Feb 22, 2014 at 1:00 PM, Till Schneidereit
wrote:
>
>> If your data is read-only after the point at which Nuwa forks the
>> process (which is once things are mostly loaded but before we load the
>> app) then generally yes. It's copy-on-write at page granularity of
>> course, so if you hav
On Sat, Feb 22, 2014 at 2:31 PM, Kyle Huey wrote:
> On Fri, Feb 21, 2014 at 5:28 PM, Till Schneidereit
> wrote:
> > Does that mean that bug 964057[1] will automatically cause all
> self-hosting
> > state to be shared amongst content processes, too?
> >
> > [1]: https://bugzilla.mozilla.org/show_
On Fri, Feb 21, 2014 at 5:28 PM, Till Schneidereit
wrote:
> Does that mean that bug 964057[1] will automatically cause all self-hosting
> state to be shared amongst content processes, too?
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=964057
>
>
> On Sat, Feb 22, 2014 at 2:12 PM, Kyle Huey
Does that mean that bug 964057[1] will automatically cause all self-hosting
state to be shared amongst content processes, too?
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=964057
On Sat, Feb 22, 2014 at 2:12 PM, Kyle Huey wrote:
> On Fri, Feb 21, 2014 at 5:07 PM, Jason Duell
> wrote:
> >
On Fri, Feb 21, 2014 at 5:07 PM, Jason Duell wrote:
> On 02/21/2014 01:38 PM, Nicholas Nethercote wrote:
>>
>> Greetings,
>>
>> We now live in a memory-constrained world. By "we", I mean anyone
>> working on Mozilla platform code. When desktop Firefox was our only
>> product, this wasn't especiall
On 02/21/2014 01:38 PM, Nicholas Nethercote wrote:
Greetings,
We now live in a memory-constrained world. By "we", I mean anyone
working on Mozilla platform code. When desktop Firefox was our only
product, this wasn't especially true -- bad leaks and the like were a
problem, sure, but ordinary us
On Sat, Feb 22, 2014 at 9:40 AM, Brian Smith wrote:
>
> How worthwhile is it to cut 100KiB from the parent process?
We don't have a fixed memory budget per se. If it's easy and doesn't
have bad side-effects, do it. Otherwise... use your judgment. Having a
Firefox OS device to test on helps with e
On Sat, Feb 22, 2014 at 9:30 AM, David Rajchenbach-Teller
wrote:
> Does this memory-constrained policy apply only to release builds or also
> to debug builds?
Debug builds are definitely less important. But it's also nice to not
have big differences between debug and opt builds. E.g. in
https://b
Caches are fine in the child process as long they are reasonably sized, and
they purge themselves in case of a low-memory notification.
On FFOS the parent process never dies, so leaks or long-lived memory allocation
there tends to hurt. Responding to low-memory notifications is really important
On Fri, Feb 21, 2014 at 1:38 PM, Nicholas Nethercote
wrote:
> Optimizations that wouldn't have been worthwhile in the desktop-only
> days are now worthwhile. For example, an optimization that saves 100
> KiB of memory per process is pretty worthwhile for Firefox OS.
Do you mean 100KiB per child p
Does this memory-constrained policy apply only to release builds or also
to debug builds?
Cheers,
David
On 2/21/14 10:38 PM, Nicholas Nethercote wrote:
> Greetings,
>
> We now live in a memory-constrained world. By "we", I mean anyone
> working on Mozilla platform code. When desktop Firefox was
Greetings,
We now live in a memory-constrained world. By "we", I mean anyone
working on Mozilla platform code. When desktop Firefox was our only
product, this wasn't especially true -- bad leaks and the like were a
problem, sure, but ordinary usage wasn't much of an issue. But now
with Firefox on
On 2/21/14 6:07 AM, Masayuki Nakano wrote:
nsDOMEvent will be just "Event".
Just like Element is just Element as long as you're in DOM code, yes.
This is a good thing, imo.
Of course in code not in the mozilla::dom namespace, you get
mozilla::dom::Event or dom::Event, which seems fine to me
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
PDT.
The next meeting will take place on Monday, February 24th at 5:30 PM US/Pacific
Please add to the agenda: https://wiki.mozilla.org/Platform/
On 2014/02/21 20:21, Neil wrote:
And also the header file name will be "Event.h".
Won't it be "mozilla/dom/Event.h" ?
Oh, good point.
http://mxr.mozilla.org/mozilla-central/source/dom/events/moz.build#38
38 EXPORTS.mozilla.dom += [
39 'EventTarget.h',
40 'PointerEvent.h',
41 'To
Masayuki Nakano wrote:
nsDOMEvent will be just "Event".
Well, only if you're using the mozilla::dom namespace.
And also the header file name will be "Event.h".
Won't it be "mozilla/dom/Event.h" ?
--
Warning: May contain traces of nuts.
___
dev-p
Hi, there were similar two keyCode constants, one was VK_RETURN
(DOM_VK_RETURN/NS_VK_RETURN), the other was VK_ENTER
(DOM_VK_ENTER/NS_VK_ENTER).
These were making a lot of developers confused and event handlers
duplicated.
Now, VK_ENTER has gone. See bug 969247 for the detail.
https://bugzil
Hi,
On 2014/02/12 23:22, Boris Zbarsky wrote:
On 2/12/14 4:46 AM, Masayuki Nakano wrote:
I'm not sure which is the best name for the classes. E.g., DOMWheelEvent
vs. PointerEvent.
I believe in this case PointerEvent is correct, because
http://www.w3.org/TR/pointerevents/#pointerevent-interfac
JoeS wrote:
I tried hacking the following into the tail end of msvc11.bat file in
mozilla-build:
Try setting MOZ_MAXWINSDK=70100
Alternatively, try installing the SDK 7.1 compilers and use the
msvc10.bat file. (You can still use the VS debugger.)
--
Warning: May contain traces of nuts.
___
On 02/21/2014 12:01 AM, Honza Bambas wrote:
On 2/20/2014 10:25 PM, Neil wrote:
Well, that was confusing.
The old contract ID was @mozilla.org/network/cache-service;1
The new contract ID is @mozilla.org/netwerk/cache-storage-service;1
Turns out that there are two differences, not one.
Yes, forg
20 matches
Mail list logo
