Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
Servo already atomizes the counter names, it makes no sense to copy the string
rather than bumping the refcount.
Differential Revision: https://phabricator.services.mozilla.com/D27061
--HG--
extra : moz-landing-system : lando
Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to ResolveSameStructsAs, and
get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to
ResolveSameStructsAs, and get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
Doing it during layout instead. This also has the nice side-effect of
no longer needing to do a full restyle when counter-style rules are inserted.
Differential Revision: https://phabricator.services.mozilla.com/D18343
We are using the unrounded dest rect to calculate the image decode size
in ComputeImageContainerDrawingParameters, while passing the rounded
dest rect to WebRender. This mismatch causes images to be decoded to one
size and display at another, cause some visual distortions. Using the
correct rect seems to allow us to remove the extra snapping logic added
to work around this.
At this time, how we snap is different between WebRender and
non-WebRender in general. This patch will likely morph again once we
bring the two models closer together.
Differential Revision: https://phabricator.services.mozilla.com/D15739
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
If we do not pass the high quality scaling flag than the resulting surface will be marked as cannot substitute, which is not accurate, so we don't want.
The only place that actually tries to be smart about the size is nsImageFrame::MaybeDecodeForPredictedSize. All other cases just ask for the intrinsic size.
The two most likely cases are that there are no decoded copies of the image, or there is one decoded (or in progress) copy of the image.
In the first case we will request decode at the instrinsic size, and then if we draw at a different size that draw will request the proper size. This doesn't change with this patch.
In the second case there is a decoded copy already available, this is likely from a draw call on the image, and that is the surface size that we want. So we save a decode. If we are actually drawing the image at two different sizes the second size will be slightly delayed, but we have the wrongly sized copy of the image that we can draw until then. This seems like a good tradeoff to avoid always decoding an instrinic size copy of images.
When generating display lists for WebRender, we were not caching the
draw result via nsDisplayItemGenericImageGeometry::UpdateDrawResult (or
similar) after completing CreateWebRenderCommands. This is important
because reftests use this to force sync decoding for images; it may be a
reason for image-related intermittent failures on *-qr builds.
Additionally, we may have been requesting fallback in cases where fallback
could not do anything more than WebRender could. For example, if we can't
get an image container yet, there is no point in requesting fallback
because it might just be we haven't started decoding yet. We should just
return the actual draw result in such cases.
In addition to the image container, the draw result can also be useful
for callers to know whether or not the surface(s) in the container are
fully decoded or not. This is used in subsequent parts to avoid
flickering in some cases.
Use the ImageRendering needed for Bug 1488555 to provide the correct ImageRendering argument for the PushImage call at the end of CreateWebRenderCommandsForImage instead of always using Auto filtering.
Introduce an ImageRendering argument for CreateImageKey which is then used at the CreateAsyncImageWebRenderCommands call to provide the proper filtering instead of using always Auto filtering. Update all calls to CreateImageKey to use the new interface.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Andreea Pavel
Dan Glastonbury
Mats Palmgren
Masayuki Nakano
Emilio Cobos Álvarez
Csoregi Natalia
Daniel Holbert
Matt Woodrow
Sylvestre Ledru
Cameron McCormack
Ryan Hunt
Razvan Maries
Ehsan Akhgari
Andrew Osmond
Dzmitry Malyshau
Doug Thayer
Miko Mynttinen
Cosmin Sabou
Timothy Nikkel
Dorel Luca
Zhang Junzhi
Henrik Winnemöller
Lee Salzman
Bas Schouten
Andi-Bogdan Postelnicu