gecko-dev/layout/generic/nsFontInflationData.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

71 строка
2.3 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
/* Per-block-formatting-context manager of font size inflation for pan and zoom
* UI. */
#ifndef nsFontInflationData_h_
#define nsFontInflationData_h_
#include "nsContainerFrame.h"
class nsFontInflationData {
using ReflowInput = mozilla::ReflowInput;
public:
static nsFontInflationData* FindFontInflationDataFor(const nsIFrame* aFrame);
Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron When one of the two factors governing the effective container width for font inflation changes, we need to mark all affected frames as dirty. While the visible area commonly changes because of viewport changes and we can catch those through the check for ISize resizes of the top-level frame ("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation of the effective container width into the FontInflationData itself, especially since the effective container width calculation in nsLayoutUtils is the only consumer of the NCAISize currently stored by the FontInflationData. That way - we can be sure that really all changes of the visible width will correctly mark all affected frames as dirty - can avoid repeatedly recalculating the effective container width - can also detect the cases where the effective container width actually remains the same after a change in one of its input factors and skip forcing a full dirty reflow for all descendants just because of font inflation. While the code in nsLayoutUtils was technically always using the writing mode (horizontal/vertical) of each individual frame for determining which dimension of the visible size should be used for clamping, just using the writing mode of the respective flow root should be enough, since each change in the writing mode should create a new flow root. This assumption should already hold today because 1. as per the Writing Modes CSS spec, a change in writing mode compared to its parent means that the affected block cannot be purely "inline", but at most "inline-block". 2. Generally, any non-inline frame will be marked as a font inflation container. 3. Any block frame whose writing direction doesn't match its parent will be a block formatting context, which implies NS_BLOCK_FLOAT_MGR. 4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation container will also become a font inflation flow root. but because this chain of reasoning is not the most direct, we also add a corresponding assertion to better catch any potential bugs here. Differential Revision: https://phabricator.services.mozilla.com/D5578 --HG-- extra : moz-landing-system : lando
2018-10-02 18:23:17 +03:00
// Returns whether the usable width changed (which requires the
// caller to mark its descendants dirty)
static bool UpdateFontInflationDataISizeFor(const ReflowInput& aReflowInput);
static void MarkFontInflationDataTextDirty(nsIFrame* aFrame);
bool InflationEnabled() {
if (mTextDirty) {
ScanText();
}
return mInflationEnabled;
}
Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron When one of the two factors governing the effective container width for font inflation changes, we need to mark all affected frames as dirty. While the visible area commonly changes because of viewport changes and we can catch those through the check for ISize resizes of the top-level frame ("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation of the effective container width into the FontInflationData itself, especially since the effective container width calculation in nsLayoutUtils is the only consumer of the NCAISize currently stored by the FontInflationData. That way - we can be sure that really all changes of the visible width will correctly mark all affected frames as dirty - can avoid repeatedly recalculating the effective container width - can also detect the cases where the effective container width actually remains the same after a change in one of its input factors and skip forcing a full dirty reflow for all descendants just because of font inflation. While the code in nsLayoutUtils was technically always using the writing mode (horizontal/vertical) of each individual frame for determining which dimension of the visible size should be used for clamping, just using the writing mode of the respective flow root should be enough, since each change in the writing mode should create a new flow root. This assumption should already hold today because 1. as per the Writing Modes CSS spec, a change in writing mode compared to its parent means that the affected block cannot be purely "inline", but at most "inline-block". 2. Generally, any non-inline frame will be marked as a font inflation container. 3. Any block frame whose writing direction doesn't match its parent will be a block formatting context, which implies NS_BLOCK_FLOAT_MGR. 4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation container will also become a font inflation flow root. but because this chain of reasoning is not the most direct, we also add a corresponding assertion to better catch any potential bugs here. Differential Revision: https://phabricator.services.mozilla.com/D5578 --HG-- extra : moz-landing-system : lando
2018-10-02 18:23:17 +03:00
nscoord UsableISize() const { return mUsableISize; }
private:
explicit nsFontInflationData(nsIFrame* aBFCFrame);
nsFontInflationData(const nsFontInflationData&) = delete;
void operator=(const nsFontInflationData&) = delete;
void UpdateISize(const ReflowInput& aReflowInput);
enum SearchDirection { eFromStart, eFromEnd };
static nsIFrame* FindEdgeInflatableFrameIn(nsIFrame* aFrame,
SearchDirection aDirection);
void MarkTextDirty() { mTextDirty = true; }
void ScanText();
// Scan text in the subtree rooted at aFrame. Increment mTextAmount
// by multiplying the number of characters found by the font size
// (yielding the inline-size that would be occupied by the characters if
// they were all em squares). But stop scanning if mTextAmount
// crosses mTextThreshold.
void ScanTextIn(nsIFrame* aFrame);
static const nsIFrame* FlowRootFor(const nsIFrame* aFrame) {
while (!(aFrame->GetStateBits() & NS_FRAME_FONT_INFLATION_FLOW_ROOT)) {
aFrame = aFrame->GetParent();
}
return aFrame;
}
nsIFrame* mBFCFrame;
Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron When one of the two factors governing the effective container width for font inflation changes, we need to mark all affected frames as dirty. While the visible area commonly changes because of viewport changes and we can catch those through the check for ISize resizes of the top-level frame ("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation of the effective container width into the FontInflationData itself, especially since the effective container width calculation in nsLayoutUtils is the only consumer of the NCAISize currently stored by the FontInflationData. That way - we can be sure that really all changes of the visible width will correctly mark all affected frames as dirty - can avoid repeatedly recalculating the effective container width - can also detect the cases where the effective container width actually remains the same after a change in one of its input factors and skip forcing a full dirty reflow for all descendants just because of font inflation. While the code in nsLayoutUtils was technically always using the writing mode (horizontal/vertical) of each individual frame for determining which dimension of the visible size should be used for clamping, just using the writing mode of the respective flow root should be enough, since each change in the writing mode should create a new flow root. This assumption should already hold today because 1. as per the Writing Modes CSS spec, a change in writing mode compared to its parent means that the affected block cannot be purely "inline", but at most "inline-block". 2. Generally, any non-inline frame will be marked as a font inflation container. 3. Any block frame whose writing direction doesn't match its parent will be a block formatting context, which implies NS_BLOCK_FLOAT_MGR. 4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation container will also become a font inflation flow root. but because this chain of reasoning is not the most direct, we also add a corresponding assertion to better catch any potential bugs here. Differential Revision: https://phabricator.services.mozilla.com/D5578 --HG-- extra : moz-landing-system : lando
2018-10-02 18:23:17 +03:00
nscoord mUsableISize;
nscoord mTextAmount, mTextThreshold;
bool mInflationEnabled; // for this BFC
bool mTextDirty;
};
#endif /* !defined(nsFontInflationData_h_) */