This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient.
Previously, mix-blend mode was composed in the following way:
1. parent stacking context was forced to isolate
2. source picture is also isolated
3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache.
4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop
The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic:
1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible.
2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture
3. the instance of the backdrop picture is placed as a peer of the source picture (not a child)
4. if the backdrop is invisible, the source is drawn as a simple blit
5. otherwise, it's a draw call that reads from the isolated backdrop and source textures
Note the differences:
- parent stacking context is not isolated, but backdrop is
- no framebuffer readback is involved
- the source and backdrop pictures are rendered in parallel in a pass, improving the batching
- we don't blend onto the backdrop while reading from the backdrop copy at the same time
- the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings
Differential Revision: https://phabricator.services.mozilla.com/D20608
--HG--
rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml
rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml
extra : moz-landing-system : lando
If cue div is not a pseudo element, which means we don't have a default style applying on it. Therefore, we should set the default css style for it.
Differential Revision: https://phabricator.services.mozilla.com/D19864
--HG--
extra : moz-landing-system : lando
CueStyleBox should handle all css attributes, so it make more sense to adjust font size and style inside CueStyleBox.
Differential Revision: https://phabricator.services.mozilla.com/D19719
--HG--
extra : moz-landing-system : lando
Using class syntax for CueStyleBox made us easier to simplify the code and make it more readable.
Differential Revision: https://phabricator.services.mozilla.com/D19252
--HG--
extra : moz-landing-system : lando
There is no need to check whether the code is running on other browser, because we won't upstream the change back to the github repo, as this code uses a lots mozilla-only APIs.
Differential Revision: https://phabricator.services.mozilla.com/D19251
--HG--
extra : moz-landing-system : lando
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
This simply lets you request 'count' random bytes. A SHA-256 digest is
included for verifying the integrity of the response.
Differential Revision: https://phabricator.services.mozilla.com/D19503
--HG--
extra : moz-landing-system : lando
The basic idea is to make non-initial about:blank fire
document-element-inserted notifications just like every other document. We
then ensure that there's a notification (initial-document-element-inserted)
that only gets fired once per window for documents that are in a window. This
notification is what webextensions use to inject into the document.
The old setup which injected into about:blank when its global is created gets
removed in favor of injecting the same way as into every other document.
The changes to Document.cpp are fixing a bug in the "block the parser" stuff
webextensions do. For about:blank, the blocking happens at a point when the
parser really has nothing else to parse (since it's parsing the empty string).
So the blocking is a no-op. But we do want to prevent DOMContentLoaded firing,
because otherwise the "end of document" scripts could run before we finish
doing the "beginning of document" work in webextensions. So we want to make
sure we block DOMContentLoaded, not just the load event.
Differential Revision: https://phabricator.services.mozilla.com/D19892
--HG--
extra : moz-landing-system : lando
Otherwise we get a performance regression on tp5o responsiveness and
tp5o_webext responsiveness when about:blank starts firing
document-element-inserted notifications.
Differential Revision: https://phabricator.services.mozilla.com/D20873
--HG--
extra : moz-landing-system : lando
We had previously missed to call browser.updateSecurityUIForContentBlockingEvent on
onLocationChange updates, to reset the contentBlockingEvent state. This would mean that
on tab switch the contentBlockingEvent state for benign pages would still be what it was
set to on the last tracker page.
Differential Revision: https://phabricator.services.mozilla.com/D20328
--HG--
extra : moz-landing-system : lando
This warning (as an error) is showing up with this patch due to the new
use of AddEventListenerOptions in ChromeUtilsBinding.h. That header is
included in some codegen units which have this warning enabled, which
revealed the issue.
I believe the warning is spurious in this case, but fixing it doesn't
seem like a big deal. Requesting review from Boris, as he added the
comment 6 years ago.
Depends on D20015
Differential Revision: https://phabricator.services.mozilla.com/D20824
--HG--
extra : moz-landing-system : lando
This patch takes the approach of keeping track of a list of nsWindowRoot
objects in the JSWindowActorService. Listeners are then maintained for
each type of actor for every nsWindowRoot.
Depends on D20012
Differential Revision: https://phabricator.services.mozilla.com/D20013
--HG--
extra : moz-landing-system : lando
Currently, some of the JS allocators accept an 'arena' argument, but some
don't. This change makes it so they all do. This is nice for consistency, but
it also feeds into Bug 1052579, which will need to use arenas for JSString
backing buffers.
Differential Revision: https://phabricator.services.mozilla.com/D19717
--HG--
extra : moz-landing-system : lando
Previously we were using NS_GetLuminosity which asserts for non-opaque colors,
and my system theme happens to use a background color with alpha=0.999.
Luminosity judgements do get a bit more hand-wavy as colors get more
transparent, but it seems like we can still reasonably make an overall
"dark theme" judgement based on the RGB channels.
Differential Revision: https://phabricator.services.mozilla.com/D20748
--HG--
extra : moz-landing-system : lando
BasicDllServices is used to gain access to the authenticode APIs in non-Gecko
contexts. One feature that WinDllServices provides is the ability to register
a callback interface to be notified when a DLL has been loaded.
This is not particularly useful in the BasicDllServices use case, and in the
"handle a launcher process failure on a background thread" use case, would
actually be harmful.
This patch modifies the DLLServices backend to offer a "basic" option that
omits the callback stuff.
Differential Revision: https://phabricator.services.mozilla.com/D19696
--HG--
extra : moz-landing-system : lando
Remove the ability for fake plugins to create frames. Fake plugins
aren't used anymore, so we can simplify nsFrameLoader a bit by
removing some of the related checks.
Differential Revision: https://phabricator.services.mozilla.com/D20430
--HG--
extra : moz-landing-system : lando
This may lose some tiny amount of performance since the existing code
duplicated a huge amount of code in order to avoid walking bits of the tree
that can't contain functions. I preserved a few of those hacks but some of the
bits seemed too small to bother with.
The expression `nparents_ - 1` is changed to `nparents_ - 2` because, as a
result of how ParseNodeVisitor control flow works, we now call gatherNameable
*after* pushing the current FunctionNode to the stack, rather than before.
(A new assertion checks that this is the case.)
Differential Revision: https://phabricator.services.mozilla.com/D20720
--HG--
extra : moz-landing-system : lando
This is meant as a sanity patch. Before, buf_ was a pointer to a local
variable, set in resolveFun() and just left dangling on exit. No bug, but
dangling pointers are bad.
I considered removing buf_ and passing around a reference to the local
StringBuffer, but this was quicker and seemed easier to review.
Differential Revision: https://phabricator.services.mozilla.com/D20719
--HG--
extra : moz-landing-system : lando
The `Expr` suffix is for nodes that can appear anywhere an expression could
appear. This kind of node can't; it's always the direct child of a tagged
template.
Differential Revision: https://phabricator.services.mozilla.com/D20717
--HG--
extra : moz-landing-system : lando
I tried making ParseNodeVisitor take all nodes as references, but that didn't
work nicely with the existing accept() method templates. That could have been
made to work using more template tricks, but I decided pointers are not so bad.
There still was no way to avoid the code duplication here without contortions.
Differential Revision: https://phabricator.services.mozilla.com/D20716
--HG--
extra : moz-landing-system : lando
Some functionality is intentionally unimplemented to make this patch
smaller and at a faster cadence: field initializers are stored on
this['.initializers'] instead of a local, derived classes are not
supported yet, and constant-folding/inline field initializers are not
implemented.
Differential Revision: https://phabricator.services.mozilla.com/D16343
--HG--
extra : moz-landing-system : lando
Support for `kind='task'` is still around to support Thunderbird release
promotion, which uses releaserunner3. Other actions shouldn't be using it.
Differential Revision: https://phabricator.services.mozilla.com/D20842
--HG--
extra : moz-landing-system : lando
