gecko-dev/layout/generic/TextDrawTarget.h

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

605 строки
22 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: */
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03: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/. */
#ifndef TextDrawTarget_h
#define TextDrawTarget_h
#include "mozilla/gfx/2D.h"
#include "mozilla/layers/RenderRootStateManager.h"
#include "mozilla/layers/WebRenderLayerManager.h"
#include "mozilla/layers/WebRenderBridgeChild.h"
#include "mozilla/webrender/WebRenderAPI.h"
#include "mozilla/layers/StackingContextHelper.h"
#include "mozilla/layers/IpcResourceUpdateQueue.h"
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
namespace mozilla {
namespace layout {
using namespace gfx;
// This class is fake DrawTarget, used to intercept text draw calls, while
// also collecting up the other aspects of text natively.
//
// When using advanced-layers in nsDisplayText's constructor, we construct this
// and run the full painting algorithm with this as the DrawTarget. This is
// done to avoid having to massively refactor gecko's text painting code (which
// has lots of components shared between other rendering algorithms).
//
// In some phases of the painting algorithm, we can grab the relevant values
// and feed them directly into TextDrawTarget. For instance, selections,
// decorations, and shadows are handled in this manner. In those cases we can
// also short-circuit the painting algorithm to save work.
//
// In other phases, the computed values are sufficiently buried in complex
// code that it's best for us to just intercept the final draw calls. This
// is how we handle computing the glyphs of the main text and text-emphasis
// (see our overloaded FillGlyphs implementation).
//
// To be clear: this is a big hack. With time we hope to refactor the codebase
// so that all the elements of text are handled directly by TextDrawTarget,
// which is to say everything is done like we do selections and shadows now.
// This design is a good step for doing this work incrementally.
//
// This is also likely to be a bit buggy (missing or misinterpreted info)
// while we further develop the design.
//
// TextDrawTarget doesn't yet support all features. See mHasUnsupportedFeatures
// for details.
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
class TextDrawTarget : public DrawTarget {
public:
explicit TextDrawTarget(wr::DisplayListBuilder& aBuilder,
wr::IpcResourceUpdateQueue& aResources,
const layers::StackingContextHelper& aSc,
layers::RenderRootStateManager* aManager,
nsDisplayItem* aItem, nsRect& aBounds,
bool aCallerDoesSaveRestore = false)
: mCallerDoesSaveRestore(aCallerDoesSaveRestore), mBuilder(aBuilder) {
Reinitialize(aResources, aSc, aManager, aItem, aBounds);
}
// Prevent this from being copied
TextDrawTarget(const TextDrawTarget& src) = delete;
TextDrawTarget& operator=(const TextDrawTarget&) = delete;
~TextDrawTarget() { MOZ_ASSERT(mFinished); }
void Reinitialize(wr::IpcResourceUpdateQueue& aResources,
const layers::StackingContextHelper& aSc,
layers::RenderRootStateManager* aManager,
nsDisplayItem* aItem, nsRect& aBounds) {
mResources = &aResources;
mSc = &aSc;
mManager = aManager;
mHasUnsupportedFeatures = false;
mHasShadows = false;
SetPermitSubpixelAA(!aItem->IsSubpixelAADisabled());
// Compute clip/bounds
auto appUnitsPerDevPixel =
aItem->Frame()->PresContext()->AppUnitsPerDevPixel();
LayoutDeviceRect layoutBoundsRect =
LayoutDeviceRect::FromAppUnits(aBounds, appUnitsPerDevPixel);
LayoutDeviceRect layoutClipRect = layoutBoundsRect;
mBoundsRect = wr::ToRoundedLayoutRect(layoutBoundsRect);
// Add 1 pixel of dirty area around clip rect to allow us to paint
// antialiased pixels beyond the measured text extents.
layoutClipRect.Inflate(1);
mSize = IntSize::Ceil(layoutClipRect.Width(), layoutClipRect.Height());
mClipStack.ClearAndRetainStorage();
mClipStack.AppendElement(layoutClipRect);
mBackfaceVisible = !aItem->BackfaceIsHidden();
if (!mCallerDoesSaveRestore) {
mBuilder.Save();
}
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void FoundUnsupportedFeature() { mHasUnsupportedFeatures = true; }
bool CheckHasUnsupportedFeatures() {
MOZ_ASSERT(mCallerDoesSaveRestore);
#ifdef DEBUG
MOZ_ASSERT(!mFinished);
mFinished = true;
#endif
return mHasUnsupportedFeatures;
}
bool Finish() {
MOZ_ASSERT(!mCallerDoesSaveRestore);
#ifdef DEBUG
mFinished = true;
#endif
if (mHasUnsupportedFeatures) {
mBuilder.Restore();
return false;
}
mBuilder.ClearSave();
return true;
}
wr::FontInstanceFlags GetWRGlyphFlags() const { return mWRGlyphFlags; }
void SetWRGlyphFlags(wr::FontInstanceFlags aFlags) { mWRGlyphFlags = aFlags; }
class AutoRestoreWRGlyphFlags {
public:
~AutoRestoreWRGlyphFlags() {
if (mTarget) {
mTarget->SetWRGlyphFlags(mFlags);
}
}
void Save(TextDrawTarget* aTarget) {
// This allows for recursive saves, in case the flags need to be modified
// under multiple conditions (i.e. transforms and synthetic italics),
// since the flags will be restored to the first saved value in the
// destructor on scope exit.
if (!mTarget) {
// Only record the first save with the original flags that will be
// restored.
mTarget = aTarget;
mFlags = aTarget->GetWRGlyphFlags();
} else {
// Ensure that this is actually a recursive save to the same target
MOZ_ASSERT(
mTarget == aTarget,
"Recursive save of WR glyph flags to different TextDrawTargets");
}
}
private:
TextDrawTarget* mTarget = nullptr;
wr::FontInstanceFlags mFlags = {0};
};
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
// This overload just stores the glyphs/font/color.
void FillGlyphs(ScaledFont* aFont, const GlyphBuffer& aBuffer,
const Pattern& aPattern,
const DrawOptions& aOptions) override {
// Make sure we're only given boring color patterns
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
MOZ_RELEASE_ASSERT(aOptions.mCompositionOp == CompositionOp::OP_OVER);
MOZ_RELEASE_ASSERT(aOptions.mAlpha == 1.0f);
MOZ_RELEASE_ASSERT(aPattern.GetType() == PatternType::COLOR);
// Make sure the font exists, and can be serialized
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
MOZ_RELEASE_ASSERT(aFont);
if (!aFont->CanSerialize()) {
FoundUnsupportedFeature();
return;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
auto* colorPat = static_cast<const ColorPattern*>(&aPattern);
auto color = wr::ToColorF(colorPat->mColor);
MOZ_ASSERT(aBuffer.mNumGlyphs);
auto glyphs = Range<const wr::GlyphInstance>(
reinterpret_cast<const wr::GlyphInstance*>(aBuffer.mGlyphs),
aBuffer.mNumGlyphs);
// MSVC won't let us use offsetof on the following directly so we give it a
// name with typedef
typedef std::remove_reference<decltype(aBuffer.mGlyphs[0])>::type GlyphType;
// Compare gfx::Glyph and wr::GlyphInstance to make sure that they are
// structurally equivalent to ensure that our cast above was ok
static_assert(
std::is_same<decltype(aBuffer.mGlyphs[0].mIndex),
decltype(glyphs[0].index)>() &&
std::is_same<decltype(aBuffer.mGlyphs[0].mPosition.x),
decltype(glyphs[0].point.x)>() &&
std::is_same<decltype(aBuffer.mGlyphs[0].mPosition.y),
decltype(glyphs[0].point.y)>() &&
offsetof(GlyphType, mIndex) == offsetof(wr::GlyphInstance, index) &&
offsetof(GlyphType, mPosition) ==
offsetof(wr::GlyphInstance, point) &&
offsetof(decltype(aBuffer.mGlyphs[0].mPosition), x) ==
offsetof(decltype(glyphs[0].point), x) &&
offsetof(decltype(aBuffer.mGlyphs[0].mPosition), y) ==
offsetof(decltype(glyphs[0].point), y) &&
std::is_standard_layout<
std::remove_reference<decltype(aBuffer.mGlyphs[0])>>::value &&
std::is_standard_layout<
std::remove_reference<decltype(glyphs[0])>>::value &&
sizeof(aBuffer.mGlyphs[0]) == sizeof(glyphs[0]) &&
sizeof(aBuffer.mGlyphs[0].mPosition) == sizeof(glyphs[0].point),
"glyph buf types don't match");
wr::GlyphOptions glyphOptions;
glyphOptions.render_mode =
wr::ToFontRenderMode(aOptions.mAntialiasMode, GetPermitSubpixelAA());
glyphOptions.flags = mWRGlyphFlags;
mManager->WrBridge()->PushGlyphs(mBuilder, glyphs, aFont, color, *mSc,
mBoundsRect, ClipRect(), mBackfaceVisible,
&glyphOptions);
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
void PushClipRect(const Rect& aRect) override {
LayoutDeviceRect rect = LayoutDeviceRect::FromUnknownRect(aRect);
rect = rect.Intersect(mClipStack.LastElement());
mClipStack.AppendElement(rect);
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
}
void PopClip() override { mClipStack.RemoveLastElement(); }
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
IntSize GetSize() const override { return mSize; }
void AppendShadow(const wr::Shadow& aShadow) {
mBuilder.PushShadow(mBoundsRect, ClipRect(), mBackfaceVisible, aShadow);
mHasShadows = true;
}
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
void TerminateShadows() {
if (mHasShadows) {
mBuilder.PopAllShadows();
mHasShadows = false;
}
}
void AppendSelectionRect(const LayoutDeviceRect& aRect, const Color& aColor) {
auto rect = wr::ToLayoutRect(aRect);
auto color = wr::ToColorF(aColor);
mBuilder.PushRect(rect, ClipRect(), mBackfaceVisible, color);
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
// This function is basically designed to slide into the decoration drawing
// code of nsCSSRendering with minimum disruption, to minimize the
// chances of implementation drift. As such, it mostly looks like a call
// to a skia-style StrokeLine method: two end-points, with a thickness
// and style. Notably the end-points are *centered* in the block direction,
// even though webrender wants a rect-like representation, where the points
// are on corners.
//
// So we mangle the format here in a single centralized place, where neither
// webrender nor nsCSSRendering has to care about this mismatch.
//
// NOTE: we assume the points are axis-aligned, and aStart should be used
// as the top-left corner of the rect.
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
void AppendDecoration(const Point& aStart, const Point& aEnd,
const float aThickness, const bool aVertical,
const Color& aColor, const uint8_t aStyle) {
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
auto pos = LayoutDevicePoint::FromUnknownPoint(aStart);
LayoutDeviceSize size;
if (aVertical) {
pos.x -= aThickness / 2; // adjust from center to corner
size = LayoutDeviceSize(aThickness, aEnd.y - aStart.y);
} else {
pos.y -= aThickness / 2; // adjust from center to corner
size = LayoutDeviceSize(aEnd.x - aStart.x, aThickness);
}
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
wr::Line decoration;
decoration.bounds = wr::ToRoundedLayoutRect(LayoutDeviceRect(pos, size));
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
decoration.wavyLineThickness = 0; // dummy value, unused
decoration.color = wr::ToColorF(aColor);
decoration.orientation = aVertical ? wr::LineOrientation::Vertical
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
: wr::LineOrientation::Horizontal;
switch (aStyle) {
case NS_STYLE_TEXT_DECORATION_STYLE_SOLID:
decoration.style = wr::LineStyle::Solid;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
break;
case NS_STYLE_TEXT_DECORATION_STYLE_DOTTED:
decoration.style = wr::LineStyle::Dotted;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
break;
case NS_STYLE_TEXT_DECORATION_STYLE_DASHED:
decoration.style = wr::LineStyle::Dashed;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
break;
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
// Wavy lines should go through AppendWavyDecoration
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
case NS_STYLE_TEXT_DECORATION_STYLE_WAVY:
// Double lines should be lowered to two solid lines
case NS_STYLE_TEXT_DECORATION_STYLE_DOUBLE:
default:
MOZ_CRASH("TextDrawTarget received unsupported line style");
}
mBuilder.PushLine(ClipRect(), mBackfaceVisible, decoration);
}
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
// Seperated out from AppendDecoration because Wavy Lines are completely
// different, and trying to merge the concept is more of a mess than it's
// worth.
void AppendWavyDecoration(const Rect& aBounds, const float aThickness,
const bool aVertical, const Color& aColor) {
wr::Line decoration;
decoration.bounds =
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
wr::ToRoundedLayoutRect(LayoutDeviceRect::FromUnknownRect(aBounds));
decoration.wavyLineThickness = aThickness;
decoration.color = wr::ToColorF(aColor);
decoration.orientation = aVertical ? wr::LineOrientation::Vertical
: wr::LineOrientation::Horizontal;
decoration.style = wr::LineStyle::Wavy;
mBuilder.PushLine(ClipRect(), mBackfaceVisible, decoration);
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
}
layers::WebRenderBridgeChild* WrBridge() { return mManager->WrBridge(); }
layers::WebRenderLayerManager* WrLayerManager() {
return mManager->LayerManager();
}
Maybe<wr::ImageKey> DefineImage(const IntSize& aSize, uint32_t aStride,
SurfaceFormat aFormat, const uint8_t* aData) {
wr::ImageKey key = mManager->WrBridge()->GetNextImageKey();
wr::ImageDescriptor desc(aSize, aStride, aFormat);
Range<uint8_t> bytes(const_cast<uint8_t*>(aData), aStride * aSize.height);
if (mResources->AddImage(key, desc, bytes)) {
return Some(key);
}
return Nothing();
}
void PushImage(wr::ImageKey aKey, const Rect& aBounds, const Rect& aClip,
wr::ImageRendering aFilter, const wr::ColorF& aColor) {
if (!aClip.Intersects(GeckoClipRect().ToUnknownRect())) {
return;
}
mBuilder.PushImage(wr::ToLayoutRect(aBounds), wr::ToLayoutRect(aClip), true,
aFilter, aKey, true, aColor);
}
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
private:
wr::LayoutRect ClipRect() {
return wr::ToRoundedLayoutRect(mClipStack.LastElement());
}
LayoutDeviceRect GeckoClipRect() { return mClipStack.LastElement(); }
// Whether anything unsupported was encountered. Currently:
//
// * Synthetic bold/italics
// * SVG fonts
// * Unserializable fonts
// * Tofu glyphs
// * Pratial ligatures
// * Text writing-mode
// * Text stroke
bool mHasUnsupportedFeatures = false;
// The caller promises to call Save/Restore on the builder as needed.
bool mCallerDoesSaveRestore = false;
#ifdef DEBUG
bool mFinished = false;
#endif
// Whether PopAllShadows needs to be called
bool mHasShadows = false;
// Things used to push to webrender
wr::DisplayListBuilder& mBuilder;
wr::IpcResourceUpdateQueue* mResources;
const layers::StackingContextHelper* mSc;
layers::RenderRootStateManager* mManager;
// Computed facts
IntSize mSize;
wr::LayoutRect mBoundsRect;
AutoTArray<LayoutDeviceRect, 3> mClipStack;
bool mBackfaceVisible;
wr::FontInstanceFlags mWRGlyphFlags = {0};
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
// The rest of this is dummy implementations of DrawTarget's API
public:
DrawTargetType GetType() const override {
return DrawTargetType::SOFTWARE_RASTER;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
BackendType GetBackendType() const override {
return BackendType::WEBRENDER_TEXT;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
bool IsRecording() const override { return true; }
bool IsCaptureDT() const override { return false; }
already_AddRefed<SourceSurface> Snapshot() override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<SourceSurface> IntoLuminanceSource(
LuminanceType aLuminanceType, float aOpacity) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void Flush() override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void DrawCapturedDT(DrawTargetCapture* aCaptureDT,
const Matrix& aTransform) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void DrawSurface(SourceSurface* aSurface, const Rect& aDest,
const Rect& aSource, const DrawSurfaceOptions& aSurfOptions,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void DrawFilter(FilterNode* aNode, const Rect& aSourceRect,
const Point& aDestPoint,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void DrawSurfaceWithShadow(SourceSurface* aSurface, const Point& aDest,
const Color& aColor, const Point& aOffset,
Float aSigma, CompositionOp aOperator) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void ClearRect(const Rect& aRect) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void CopySurface(SourceSurface* aSurface, const IntRect& aSourceRect,
const IntPoint& aDestination) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void FillRect(const Rect& aRect, const Pattern& aPattern,
const DrawOptions& aOptions = DrawOptions()) override {
MOZ_RELEASE_ASSERT(aPattern.GetType() == PatternType::COLOR);
if (!aRect.Intersects(GeckoClipRect().ToUnknownRect())) {
return;
}
auto rect =
wr::ToRoundedLayoutRect(LayoutDeviceRect::FromUnknownRect(aRect));
auto color =
wr::ToColorF(static_cast<const ColorPattern&>(aPattern).mColor);
mBuilder.PushRect(rect, ClipRect(), mBackfaceVisible, color);
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void StrokeRect(const Rect& aRect, const Pattern& aPattern,
const StrokeOptions& aStrokeOptions,
const DrawOptions& aOptions) override {
MOZ_RELEASE_ASSERT(aPattern.GetType() == PatternType::COLOR &&
aStrokeOptions.mDashLength == 0);
wr::LayoutSideOffsets widths = {
aStrokeOptions.mLineWidth, aStrokeOptions.mLineWidth,
aStrokeOptions.mLineWidth, aStrokeOptions.mLineWidth};
wr::ColorF color =
wr::ToColorF(static_cast<const ColorPattern&>(aPattern).mColor);
wr::BorderSide sides[4] = {{color, wr::BorderStyle::Solid},
{color, wr::BorderStyle::Solid},
{color, wr::BorderStyle::Solid},
{color, wr::BorderStyle::Solid}};
wr::BorderRadius radius = {{0, 0}, {0, 0}, {0, 0}, {0, 0}};
LayoutDeviceRect rect = LayoutDeviceRect::FromUnknownRect(aRect);
rect.Inflate(aStrokeOptions.mLineWidth / 2);
if (!rect.Intersects(GeckoClipRect())) {
return;
}
wr::LayoutRect bounds = wr::ToRoundedLayoutRect(rect);
mBuilder.PushBorder(bounds, ClipRect(), true, widths,
Range<const wr::BorderSide>(sides, 4), radius);
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void StrokeLine(const Point& aStart, const Point& aEnd,
const Pattern& aPattern, const StrokeOptions& aStrokeOptions,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void Stroke(const Path* aPath, const Pattern& aPattern,
const StrokeOptions& aStrokeOptions,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void Fill(const Path* aPath, const Pattern& aPattern,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void StrokeGlyphs(ScaledFont* aFont, const GlyphBuffer& aBuffer,
const Pattern& aPattern,
const StrokeOptions& aStrokeOptions,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void Mask(const Pattern& aSource, const Pattern& aMask,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void MaskSurface(const Pattern& aSource, SourceSurface* aMask, Point aOffset,
const DrawOptions& aOptions) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
bool Draw3DTransformedSurface(SourceSurface* aSurface,
const Matrix4x4& aMatrix) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void PushClip(const Path* aPath) override {
Bug 1401653 - fixup webrender text-decoration bindings. r=jrmuizel This does 3 things that were all a bit too intermixed to split out cleanly: 1. Teaches TextDrawTarget to handle rectangular clips (while also completely forbidding other ones). This is necessary to handle how gecko "overdraws" decorations with clips to create the illusion of continuous lines when they're actually made out of multiple lines, possibly from different display items with different lines. Previously gecko *was* handing these clips to TextDrawTarget to use these clips, but we were just ignoring them. This is also necessary work to support partial glyphs natively (which apply rectangular clips to glyphs). Also note that this currently causes a bug in webrender if combined with zero-blur shadows, but it's not a regression since we already mishandle clipped decorations. I will work on fixing this upstream. 2. Changes the intermediate representation of lines from the old webrender format to a rect-based one. This is in preperation for webrender adopting that format in a future update. 3. Changes the way wavy lines are processed, correcting some errors in the old wavy line bindings that lead to them being positioned incorrectly. Also introduces a wavyLineThickness property that the will be required in a future webrender update. Wavy lines are unlike any other line, so it's ultimately desirable to distinguish them. The net result of these changes is that a companion upstream change (webrender#1923) will make decoration rendering nearly identical to gecko, and much nicer. However the clipped shadows issue will need to be seperately resolved before actually closing this issue. MozReview-Commit-ID: 6O2wLA6bU3C --HG-- extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
2017-10-24 19:44:38 +03:00
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void PushDeviceSpaceClipRects(const IntRect* aRects,
uint32_t aCount) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void PushLayer(bool aOpaque, Float aOpacity, SourceSurface* aMask,
const Matrix& aMaskTransform, const IntRect& aBounds,
bool aCopyBackground) override {
// Fine to pretend we do this
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void PopLayer() override {
// Fine to pretend we do this
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<SourceSurface> CreateSourceSurfaceFromData(
unsigned char* aData, const IntSize& aSize, int32_t aStride,
SurfaceFormat aFormat) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<SourceSurface> OptimizeSourceSurface(
SourceSurface* aSurface) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<SourceSurface> CreateSourceSurfaceFromNativeSurface(
const NativeSurface& aSurface) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<DrawTarget> CreateSimilarDrawTarget(
const IntSize& aSize, SurfaceFormat aFormat) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
bool CanCreateSimilarDrawTarget(const IntSize& aSize,
SurfaceFormat aFormat) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return false;
}
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
already_AddRefed<PathBuilder> CreatePathBuilder(
FillRule aFillRule) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<FilterNode> CreateFilter(FilterType aType) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
already_AddRefed<GradientStops> CreateGradientStops(
GradientStop* aStops, uint32_t aNumStops,
ExtendMode aExtendMode) const override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
}
void* GetNativeSurface(NativeSurfaceType aType) override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
return nullptr;
}
void DetachAllSnapshots() override {
MOZ_CRASH("TextDrawTarget: Method shouldn't be called");
}
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h --HG-- extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
2017-06-19 17:58:28 +03:00
};
} // namespace layout
} // namespace mozilla
#endif