gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
There were some callers in nsRangeFrame that were already not-null-checking.
All platforms have a native theme and should we add new ones they could use
nsBasicNativeTheme.
Differential Revision: https://phabricator.services.mozilla.com/D65169
APZ may want to know what the main thread's view of the visual viewport offset
was at the time of the last paint even if the main thread does not want APZ
to scroll to that visual viewport offset.
Differential Revision: https://phabricator.services.mozilla.com/D62093
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
3. Add brackets for the for loop in nsCSSRendering.cpp.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_HALF_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalHalfCorners())"
rename "NS_FOR_CSS_HALF_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalHalfCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61252
Merely checking for having a displayport isn't enough, because the paint to
tell APZ about the new scroll frame could still be pending.
Differential Revision: https://phabricator.services.mozilla.com/D56662
These values start out false in the other two ways display lists can be build:
- Without retained display lists, a new nsDisplayList object is created which starts out with these values being false.
- When partial update succeeds (or at least gets far enough to run PreProcessDisplayList), RestoreState() is called on the root display list which sets these values to false.
But when partial update fails, we have an old nsDisplayList object and we were not clearing those values.
Differential Revision: https://phabricator.services.mozilla.com/D55866
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
This facilitates disabling APZ "live", such as when moving a tab from an APZ
window into a non-APZ window.
Depends on D51468
Differential Revision: https://phabricator.services.mozilla.com/D51469
Though there is another call site of UpdateCompositionBoundsForRCDRSF in
nsLayoutUtils::CalculateRootCompositionSize, it's not clear to me whether it is
necessary or not since we early return from the function in the case where
|aIsRootContentDocRootScrollFrame| argument is true. We will audit it later
in bug 1562505.
Differential Revision: https://phabricator.services.mozilla.com/D53117
Note that this FrameMetrics.mLayoutViewport doesn't represent exact size of
the layout viewport on the main thread, it means the maximum layout viewport
in future on the compositor thread once after the dynamic toolbar is completely
hidden. During the dynamic toolbar transition we don't update any information
on the main thread, which means it's possible that the visual viewport on the
compositor gets bigger than the layout viewport at the time when we send it
to the compositor thread, we have to avoid the situation.
Depends on D50419
Differential Revision: https://phabricator.services.mozilla.com/D50420
Now
* nsPresContext::mVisibleArea is excluding the toolbar max height so that
ICB is now static regardless of the dynamic toolbar transition
* nsPresContext::mSizeForViewportUnits is introduced to resolve viewport units
which is including the toolbar max height
That means that with the dynamic toolbar max height;
mVisibleArea < mSizeForViewportUnits
See https://github.com/bokand/URLBarSizing for more detail backgrounds of this
change.
Depends on D50417
Differential Revision: https://phabricator.services.mozilla.com/D50418
So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
In common cases where the caret is in a position:static frame subtree,
the caret's position (relative to canvas frame's custom content
container) should not be changed during scrolling.
However, when the caret is in a position:fixed or "stuck"
position:sticky frame subtree, the caret's position will change during
scrolling. We need to disable APZ to avoid jumpy carets.
Differential Revision: https://phabricator.services.mozilla.com/D51351
Changes here:
- Adding a "dom::" prefix in GeckoMVMContext.cpp (could've also added
a "using" decl, but I'm just adding a one-off prefix to match "dom::Document"
usage elsewhere in this file).
- Giving nsLayoutUtils an include for ViewportFrame.h since it uses that type.
- Giving nsPresArena.cpp an include for nsDisplayList.h to provide the
DisplayListArenaObjectId enum type.
Depends on D50163
Differential Revision: https://phabricator.services.mozilla.com/D50164
