It worked until now as IPC's MessageChannel was only used with background taskqueue; which use a threadpool made of a single thread only.
Differential Revision: https://phabricator.services.mozilla.com/D82499
This is a partial revert of bug 1647628.
The ImageBridgeChild's thread is used to dispatch synchronous tasks by its consumers.
While the background taskqueue is using a single thread threadpool, this would prevent many places to also use a background taskqueue that could end up calling the ImageBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D82395
Per discussion on matrix, printing mState in hex format is
indecipherable. Remove it to reduce the rate of wrapping of a long line.
Differential Revision: https://phabricator.services.mozilla.com/D82606
This is equivalent to `aFrame->DumpFrameTreeLimited()` or `ftl` gdb /
lldb command. It appears only in nsIFrame.cpp, I doubt it's actually
used by developers.
Differential Revision: https://phabricator.services.mozilla.com/D82605
This affects the output of flex, grid, fieldset, etc.
Given a snippet like the following.
```
<fieldset style="position: relative; display: flex">
<div style="position: absolute">
```
Currently, the frame tree output looks as if the AbsoluteList is under
the FieldSet, but it's actually under the FlexContainer.
```
FieldSet(fieldset)(8)@7f4ae9e73508 ... <
FlexContainer(fieldset)(8)@7f4ae9e735c0 ... <
Placeholder(div)(1)@7f4ae9e73738
>
AbsoluteList 7f4ae9dcb8c0 <
Block(div)(1)@7f4ae9e73670 ... <
>
>
>
```
After this patch, the frame tree looks like:
```
FieldSet(fieldset)(8)@7f4ae9e73508 ... <
FlexContainer(fieldset)(8)@7f4ae9e735c0 ... <
Placeholder(div)(1)@7f4ae9e73738
AbsoluteList 7f4ae9dcb8c0 <
Block(div)(1)@7f4ae9e73670 ... <
>
>
>
>
```
Another minor difference is that for a empty container, the end angle
bracket is now on its own line, which is consistent with an empty block
frame's output.
This old output
```
FlexContainer(div)(4)@7f4ae9e73390<>
```
becomes
```
FlexContainer(div)(4)@7f4ae9e73390<
>
```
Differential Revision: https://phabricator.services.mozilla.com/D82604
Make the following tweak so that they are consistent with others.
* Add a space before the open angle bracket. This is at the end of
`Block(div)(1)@7f10e25de5d0 ... <`
* Tweak nsLineBox format.
`line 7f10e25de808: count=1` becomes `line@7f10e25de808 count=1`.
* Tweak child list format.
`AbsoluteList 0x7f10e3c7e560` becomes `AbsoluteList@7f10e3c7e560`
Differential Revision: https://phabricator.services.mozilla.com/D82603
`ListChildLists` lives in nsContainerFrame because I'm going to use it
to improve nsContainerFrame::List() in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D82602
Note: This optimization saves us from doing an extra unnecessary reflow in the
mochitest test_bug1505254.html, so I'm adjusting that test to remove its
magical "+1" fudge-factor in its expectations (and the corresponding
explanatory comment). Similarly, I'm dropping the assertion-count for
crashtest 1488762-1.html because we now do a little bit less reflow work (and
hence assert a little bit less) in that test.
Depends on D78821
Differential Revision: https://phabricator.services.mozilla.com/D78822
Note: this patch doesn't change behavior of current mozilla-central - it's just reordering some logic, basically.
Background/explanation: in current mozilla-central, we intentionally force a
"final reflow" for flex items (i.e. we return true from NeedsFinalReflow) if we
see that there's a constrained AvailableBSize (i.e. if we're fragmenting). However, the
logic to do that is buried within a basically-unrelated "if
(HadMeasuringReflow())" special case.
This patch pulls that check out of this unrelated special-case, so that we
detect the constrained AvailableBSize earlier and return earlier (indicating
more eagerly/up-front that we need a final reflow).
This patch is necessary because a later patch in this queue will add additional
special cases to FlexItem::NeedsFinalReflow, which will aim to make us *skip*
the final reflow in more cases. But for now, we want this
contrained-AvailableBSize check to "dominate" and eagerly force a reflow,
regardless of that soon-to-be-added logic.
Differential Revision: https://phabricator.services.mozilla.com/D78821
The goal here is to make it so that we don't special case the device on Mac
so that we can switch GPUs without needing to reset any state.
There a couple of parts to this:
1. Disable texture storage so that we can use BGRA textures and don't need swizzling.
2. Use the recommended GL_UNSIGNED_INT_8_8_8_8_REV for BGRA on desktop GL.
3. Disable swizzling.
4. Always do the PBO workaround.
Differential Revision: https://phabricator.services.mozilla.com/D82223
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
`Scrub()` does remove leading white-spaces and trailing white-spaces if
there is. So, it does not require `WSFragment` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D82275
Bug 1650662 makes us RELEASE_ASSERT on FreeType initialization earlier
so I think it's unlikely that we ever hit this case in the future.
Differential Revision: https://phabricator.services.mozilla.com/D82390
This also updates the head.js for the about:home startup cache tests to make
sure that Pocket stories exist during the test.
Differential Revision: https://phabricator.services.mozilla.com/D80999
Endpoint would be passed by a series of std::move via
nsHttpChannel -> HttpChannelParent -> HttpBackgroundChannelParent ---> HttpBackgroundChannelChild -> HttpChannelChild
|
|
Resolve promise after successfully send IPC<-/
Depends on D81273
Differential Revision: https://phabricator.services.mozilla.com/D81274
Jean-Yves Avenard
Dão Gottwald
Simon Giesecke
Bogdan Tara
Ting-Yu Lin
Cosmin Sabou
Severin
Narcis Beleuzu
Mike Hommey
Daniel Holbert
Matthew Noorenberghe
Adam Roach [:abr]
Jeff Muizelaar
Doug Thayer
Junior Hsu
Toshihito Kikuchi
Masayuki Nakano
Kris Maglione
Logan Smyth
Shane Caraveo
Mike Conley
Tom Schuster
Nika Layzell
Scott