This is a fairly straightforward application of LOCALIZED_PP_FILES.
The extra layer of PREF_DIR can be removed because all of browser
has DIST_SUBDIR set due to it being exported in browser/moz.build, and
that means that PREF_DIR is always defaults/preferences here:
https://dxr.mozilla.org/mozilla-central/rev/f41930a869a84af81df1a88d8e82323ff3a6509a/config/rules.mk#1205
Additionally, it turns out that PREF_PPFLAGS is not set anywhere in the tree,
so I simply left it out of the translation.
MozReview-Commit-ID: 874EeTZRdLI
--HG--
extra : rebase_source : 0e585c9bd682c73b1da906d8b979cdedc05863a3
This commit adds support for handling LOCALIZED_FILES and LOCALIZED_PP_FILES
in the recursive make backend. They get special handling because they have
a few special needs:
* They run during the libs tier, so that repacks work.
* The filenames cannot be determined at build-backend generation time,
since repacks run configure once and then repack multiple locales using
the generated backend files, so they are written with to be expanded with
MERGE_FILE by make so that the file gets picked up from the proper locale dir.
Other build backends that aren't trying to handle localized builds will
silently handle these like FINAL_TARGET_FILES, which is fine until we revamp
our l10n repack story.
MozReview-Commit-ID: 2LZhPZNhQ4S
--HG--
extra : rebase_source : d0087ed10a79e94f8ecb06325e425b8bebe659d5
This commit adds new moz.build sandbox symbols that are intended to be used
for localized files: LOCALIZED_FILES and LOCALIZED_PP_FILES. They are currently
just do-nothing subclasses of FinalTarget[Preprocessor]Files, but the next
change in this series will add support for them to the recursive make backend.
Because they subclass FinalTarget[Preprocessor]Files, build backends that are
not concerned about localized builds should be able to handle them as if
they were FINAL_TARGET[_PP]_FILES without any additional code.
MozReview-Commit-ID: K0baBZ0F7av
--HG--
extra : rebase_source : 4fc3bdfcfb25142aaac873076edb92cb78032a7a
The gecko have two types of mask layer: css mask layer and the regular mask layer.
The hash key of ContainerState::mRecycledMaskImageLayers doesn't contain mask type.
So, we might get a css mask layer when we try to get a regular mask layer. Then, we
will get a nullptr of userData.
This patch add a userData checking in ContainerState::CreateOrRecycleMaskImageLayerFor()
to avoid the problem.
MozReview-Commit-ID: EEUhkctqwR2
When FLAG_HIGH_QUALITY_SCALING is used, we need to make sure we continue
using that flag when we update the container. We should also use it for
comparing whether or not an existing image container is equivalent.
This adds IsImageContainerAvailableAtSize and GetImageContainerAtSize to
the imgIContainer interface, as well as stubbing it for all of the
classes which implement it. The real implementations will follow for the
more complicated classes (RasterImage, VectorImage).
Exposure of this functionality comes in a later patch in the set.
Experimental testing with WebRender and image layers enabled suggests
most of the time we are not using more than one image container per
image, hence why mImageContainers has room for one container without a
malloc.
RasterImage::GetCurrentImage can only return a subset of the DrawResult
values, and the original RasterImage::GetImageContainer implementation
relied upon this behavior. Now we handle them all to ensure that when
other image implementations reuse it, they may return any valid
DrawResult and get the expected results.
As part of the move, we add a IntSize parameter to
ImageResource::GetCurrentImage. This is because we don't have access to
the image's size (yet) from ImageResource, but additionally because we
will need this anyways when we support multiple image containers at
different sizes.
The only change to the moved implementation is that we no longer have
access to RasterImage::mHasSize and RasterImage::mSize. Thus we rely
upon imgIContainer::IsImageContainerAvailable to perform these checks.
This state will eventually be used by VectorImage when it supports image
containers. For now, it is harmless beyond using slightly more memory
for SVGs.
