gecko-dev/gfx/layers/wr/ClipManager.cpp

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

404 строки
14 KiB
C++
Исходник Обычный вид История

Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* 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/. */
#include "mozilla/layers/ClipManager.h"
#include "DisplayItemClipChain.h"
#include "FrameMetrics.h"
#include "LayersLogging.h"
#include "mozilla/layers/StackingContextHelper.h"
#include "mozilla/layers/WebRenderLayerManager.h"
#include "mozilla/webrender/WebRenderAPI.h"
#include "nsDisplayList.h"
#include "nsStyleStructInlines.h"
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
#include "UnitTransforms.h"
// clang-format off
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
#define CLIP_LOG(...)
//#define CLIP_LOG(...) printf_stderr("CLIP: " __VA_ARGS__)
//#define CLIP_LOG(...) if (XRE_IsContentProcess()) printf_stderr("CLIP: " __VA_ARGS__)
// clang-format on
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
namespace mozilla {
namespace layers {
ClipManager::ClipManager() : mManager(nullptr), mBuilder(nullptr) {}
void ClipManager::BeginBuild(WebRenderLayerManager* aManager,
wr::DisplayListBuilder& aBuilder) {
MOZ_ASSERT(!mManager);
mManager = aManager;
MOZ_ASSERT(!mBuilder);
mBuilder = &aBuilder;
MOZ_ASSERT(mCacheStack.empty());
mCacheStack.emplace();
MOZ_ASSERT(mASROverride.empty());
MOZ_ASSERT(mItemClipStack.empty());
}
void ClipManager::EndBuild() {
mBuilder = nullptr;
mManager = nullptr;
mCacheStack.pop();
MOZ_ASSERT(mCacheStack.empty());
MOZ_ASSERT(mASROverride.empty());
MOZ_ASSERT(mItemClipStack.empty());
}
void ClipManager::BeginList(const StackingContextHelper& aStackingContext) {
if (aStackingContext.AffectsClipPositioning()) {
if (aStackingContext.ReferenceFrameId()) {
PushOverrideForASR(
mItemClipStack.empty() ? nullptr : mItemClipStack.top().mASR,
aStackingContext.ReferenceFrameId().ref());
} else {
// Start a new cache
mCacheStack.emplace();
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
ItemClips clips(nullptr, nullptr, false);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
if (!mItemClipStack.empty()) {
clips.CopyOutputsFrom(mItemClipStack.top());
}
if (aStackingContext.ReferenceFrameId()) {
clips.mScrollId = aStackingContext.ReferenceFrameId().ref();
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
mItemClipStack.push(clips);
}
void ClipManager::EndList(const StackingContextHelper& aStackingContext) {
MOZ_ASSERT(!mItemClipStack.empty());
mBuilder->SetClipChainLeaf(Nothing());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
mItemClipStack.pop();
if (aStackingContext.AffectsClipPositioning()) {
if (aStackingContext.ReferenceFrameId()) {
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
PopOverrideForASR(mItemClipStack.empty() ? nullptr
: mItemClipStack.top().mASR);
} else {
MOZ_ASSERT(!mCacheStack.empty());
mCacheStack.pop();
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
}
void ClipManager::PushOverrideForASR(const ActiveScrolledRoot* aASR,
const wr::WrSpatialId& aSpatialId) {
Maybe<wr::WrSpaceAndClip> spaceAndClip = GetScrollLayer(aASR);
MOZ_ASSERT(spaceAndClip.isSome());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
CLIP_LOG("Pushing %p override %zu -> %s\n", aASR, spaceAndClip->space.id,
Stringify(aSpatialId.id).c_str());
auto it =
mASROverride.insert({spaceAndClip->space, std::stack<wr::WrSpatialId>()});
it.first->second.push(aSpatialId);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Start a new cache
mCacheStack.emplace();
}
void ClipManager::PopOverrideForASR(const ActiveScrolledRoot* aASR) {
MOZ_ASSERT(!mCacheStack.empty());
mCacheStack.pop();
Maybe<wr::WrSpaceAndClip> spaceAndClip = GetScrollLayer(aASR);
MOZ_ASSERT(spaceAndClip.isSome());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
auto it = mASROverride.find(spaceAndClip->space);
CLIP_LOG("Popping %p override %zu -> %s\n", aASR, spaceAndClip->space.id,
Stringify(it->second.top().id).c_str());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
it->second.pop();
if (it->second.empty()) {
mASROverride.erase(it);
}
}
wr::WrSpatialId ClipManager::SpatialIdAfterOverride(
const wr::WrSpatialId& aSpatialId) {
auto it = mASROverride.find(aSpatialId);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
if (it == mASROverride.end()) {
return aSpatialId;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
MOZ_ASSERT(!it->second.empty());
CLIP_LOG("Overriding %zu with %s\n", aSpatialId.id,
Stringify(it->second.top().id).c_str());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
return it->second.top();
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
wr::WrSpaceAndClipChain ClipManager::SwitchItem(nsDisplayItem* aItem) {
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
const DisplayItemClipChain* clip = aItem->GetClipChain();
const ActiveScrolledRoot* asr = aItem->GetActiveScrolledRoot();
CLIP_LOG("processing item %p (%s) asr %p\n", aItem,
DisplayItemTypeName(aItem->GetType()), asr);
DisplayItemType type = aItem->GetType();
if (type == DisplayItemType::TYPE_STICKY_POSITION) {
// For sticky position items, the ASR is computed differently depending
// on whether the item has a fixed descendant or not. But for WebRender
// purposes we always want to use the ASR that would have been used if it
// didn't have fixed descendants, which is stored as the "container ASR" on
// the sticky item.
asr = static_cast<nsDisplayStickyPosition*>(aItem)->GetContainerASR();
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// In most cases we can combine the leaf of the clip chain with the clip rect
// of the display item. This reduces the number of clip items, which avoids
// some overhead further down the pipeline.
bool separateLeaf = false;
if (clip && clip->mASR == asr && clip->mClip.GetRoundedRectCount() == 0) {
// Container display items are not currently supported because the clip
// rect of a stacking context is not handled the same as normal display
// items.
separateLeaf = aItem->GetChildren() == nullptr;
}
ItemClips clips(asr, clip, separateLeaf);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
MOZ_ASSERT(!mItemClipStack.empty());
if (clips.HasSameInputs(mItemClipStack.top())) {
// Early-exit because if the clips are the same as aItem's previous sibling,
// then we don't need to do do the work of popping the old stuff and then
// pushing it right back on for the new item. Note that if aItem doesn't
// have a previous sibling, that means BeginList would have been called
// just before this, which will have pushed a ItemClips(nullptr, nullptr)
// onto mItemClipStack, so the HasSameInputs check should return false.
CLIP_LOG("\tearly-exit for %p\n", aItem);
return mItemClipStack.top().GetSpaceAndClipChain();
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Pop aItem's previous sibling's stuff from mBuilder in preparation for
// pushing aItem's stuff.
mItemClipStack.pop();
// Zoom display items report their bounds etc using the parent document's
// APD because zoom items act as a conversion layer between the two different
// APDs.
int32_t auPerDevPixel;
if (type == DisplayItemType::TYPE_ZOOM) {
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
auPerDevPixel =
static_cast<nsDisplayZoom*>(aItem)->GetParentAppUnitsPerDevPixel();
} else {
auPerDevPixel = aItem->Frame()->PresContext()->AppUnitsPerDevPixel();
}
// If the leaf of the clip chain is going to be merged with the display item's
// clip rect, then we should create a clip chain id from the leaf's parent.
if (separateLeaf) {
CLIP_LOG("\tseparate leaf detected, ignoring the last clip\n");
clip = clip->mParent;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
// There are two ASR chains here that we need to be fully defined. One is the
// ASR chain pointed to by |asr|. The other is the
// ASR chain pointed to by clip->mASR. We pick the leafmost
// of these two chains because that one will include the other. Calling
// DefineScrollLayers with this leafmost ASR will recursively define all the
// ASRs that we care about for this item, but will not actually push
// anything onto the WR stack.
const ActiveScrolledRoot* leafmostASR = asr;
if (clip) {
leafmostASR = ActiveScrolledRoot::PickDescendant(leafmostASR, clip->mASR);
}
Maybe<wr::WrSpaceAndClip> leafmostId = DefineScrollLayers(leafmostASR, aItem);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Define all the clips in the item's clip chain, and obtain a clip chain id
// for it.
clips.mClipChainId = DefineClipChain(clip, auPerDevPixel);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
Maybe<wr::WrSpaceAndClip> spaceAndClip = GetScrollLayer(asr);
MOZ_ASSERT(spaceAndClip.isSome());
clips.mScrollId = SpatialIdAfterOverride(spaceAndClip->space);
CLIP_LOG("\tassigning %d -> %d\n", (int)spaceAndClip->space.id,
(int)clips.mScrollId.id);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Now that we have the scroll id and a clip id for the item, push it onto
// the WR stack.
clips.UpdateSeparateLeaf(*mBuilder, auPerDevPixel);
auto spaceAndClipChain = clips.GetSpaceAndClipChain();
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
mItemClipStack.push(clips);
CLIP_LOG("done setup for %p\n", aItem);
return spaceAndClipChain;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
Maybe<wr::WrSpaceAndClip> ClipManager::GetScrollLayer(
const ActiveScrolledRoot* aASR) {
for (const ActiveScrolledRoot* asr = aASR; asr; asr = asr->mParent) {
Maybe<wr::WrSpaceAndClip> spaceAndClip =
mBuilder->GetScrollIdForDefinedScrollLayer(asr->GetViewId());
if (spaceAndClip) {
return spaceAndClip;
}
// If this ASR doesn't have a scroll ID, then we should check its ancestor.
// There may not be one defined because the ASR may not be scrollable or we
// failed to get the scroll metadata.
}
Maybe<wr::WrSpaceAndClip> spaceAndClip =
mBuilder->GetScrollIdForDefinedScrollLayer(
ScrollableLayerGuid::NULL_SCROLL_ID);
MOZ_ASSERT(spaceAndClip.isSome());
return spaceAndClip;
}
Maybe<wr::WrSpaceAndClip> ClipManager::DefineScrollLayers(
const ActiveScrolledRoot* aASR, nsDisplayItem* aItem) {
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
if (!aASR) {
// Recursion base case
return Nothing();
}
ScrollableLayerGuid::ViewID viewId = aASR->GetViewId();
Maybe<wr::WrSpaceAndClip> spaceAndClip =
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
mBuilder->GetScrollIdForDefinedScrollLayer(viewId);
if (spaceAndClip) {
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// If we've already defined this scroll layer before, we can early-exit
return spaceAndClip;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
// Recurse to define the ancestors
Maybe<wr::WrSpaceAndClip> ancestorSpaceAndClip =
DefineScrollLayers(aASR->mParent, aItem);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
Maybe<ScrollMetadata> metadata =
aASR->mScrollableFrame->ComputeScrollMetadata(
mManager, aItem->ReferenceFrame(), Nothing(), nullptr);
if (!metadata) {
MOZ_ASSERT_UNREACHABLE("Expected scroll metadata to be available!");
return ancestorSpaceAndClip;
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
FrameMetrics& metrics = metadata->GetMetrics();
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
if (!metrics.IsScrollable()) {
// This item is a scrolling no-op, skip over it in the ASR chain.
return ancestorSpaceAndClip;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
LayoutDeviceRect contentRect =
metrics.GetExpandedScrollableRect() * metrics.GetDevPixelsPerCSSPixel();
LayoutDeviceRect clipBounds =
metrics.GetCompositionBounds() /
LayoutDeviceToParentLayerScale(metrics.GetPresShellResolution());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// The content rect that we hand to PushScrollLayer should be relative to
// the same origin as the clipBounds that we hand to PushScrollLayer -
// that is, both of them should be relative to the stacking context `aSc`.
// However, when we get the scrollable rect from the FrameMetrics, the
// origin has nothing to do with the position of the frame but instead
// represents the minimum allowed scroll offset of the scrollable content.
// While APZ uses this to clamp the scroll position, we don't need to send
// this to WebRender at all. Instead, we take the position from the
// composition bounds.
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
contentRect.MoveTo(clipBounds.TopLeft());
Maybe<wr::WrSpaceAndClip> parent = ancestorSpaceAndClip;
if (parent) {
parent->space = SpatialIdAfterOverride(parent->space);
}
LayoutDevicePoint scrollOffset =
metrics.GetScrollOffset() * metrics.GetDevPixelsPerCSSPixel();
return Some(mBuilder->DefineScrollLayer(
viewId, parent, wr::ToRoundedLayoutRect(contentRect),
wr::ToRoundedLayoutRect(clipBounds), wr::ToLayoutPoint(scrollOffset)));
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
Maybe<wr::WrClipChainId> ClipManager::DefineClipChain(
const DisplayItemClipChain* aChain, int32_t aAppUnitsPerDevPixel) {
AutoTArray<wr::WrClipId, 6> clipIds;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Iterate through the clips in the current item's clip chain, define them
// in WR, and put their IDs into |clipIds|.
for (const DisplayItemClipChain* chain = aChain; chain;
chain = chain->mParent) {
ClipIdMap& cache = mCacheStack.top();
auto it = cache.find(chain);
if (it != cache.end()) {
// Found it in the currently-active cache, so just use the id we have for
// it.
CLIP_LOG("cache[%p] => %zu\n", chain, it->second.id);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
clipIds.AppendElement(it->second);
continue;
}
if (!chain->mClip.HasClip()) {
// This item in the chain is a no-op, skip over it
continue;
}
LayoutDeviceRect clip = LayoutDeviceRect::FromAppUnits(
chain->mClip.GetClipRect(), aAppUnitsPerDevPixel);
nsTArray<wr::ComplexClipRegion> wrRoundedRects;
chain->mClip.ToComplexClipRegions(aAppUnitsPerDevPixel, wrRoundedRects);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
Maybe<wr::WrSpaceAndClip> spaceAndClip = GetScrollLayer(chain->mASR);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Before calling DefineClipChain we defined the ASRs by calling
// DefineScrollLayers, so we must have a scrollId here.
MOZ_ASSERT(spaceAndClip.isSome());
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
// Define the clip
spaceAndClip->space = SpatialIdAfterOverride(spaceAndClip->space);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
wr::WrClipId clipId = mBuilder->DefineClip(
spaceAndClip, wr::ToRoundedLayoutRect(clip), &wrRoundedRects);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
clipIds.AppendElement(clipId);
cache[chain] = clipId;
CLIP_LOG("cache[%p] <= %zu\n", chain, clipId.id);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
if (clipIds.IsEmpty()) {
return Nothing();
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
return Some(mBuilder->DefineClipChain(clipIds));
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
ClipManager::~ClipManager() {
MOZ_ASSERT(!mBuilder);
MOZ_ASSERT(mCacheStack.empty());
MOZ_ASSERT(mItemClipStack.empty());
}
ClipManager::ItemClips::ItemClips(const ActiveScrolledRoot* aASR,
const DisplayItemClipChain* aChain,
bool aSeparateLeaf)
: mASR(aASR), mChain(aChain), mSeparateLeaf(aSeparateLeaf) {
mScrollId = wr::wr_root_scroll_node_id();
}
void ClipManager::ItemClips::UpdateSeparateLeaf(
wr::DisplayListBuilder& aBuilder, int32_t aAppUnitsPerDevPixel) {
Maybe<wr::LayoutRect> clipLeaf;
if (mSeparateLeaf) {
MOZ_ASSERT(mChain);
clipLeaf.emplace(wr::ToRoundedLayoutRect(LayoutDeviceRect::FromAppUnits(
mChain->mClip.GetClipRect(), aAppUnitsPerDevPixel)));
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
aBuilder.SetClipChainLeaf(clipLeaf);
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
bool ClipManager::ItemClips::HasSameInputs(const ItemClips& aOther) {
return mASR == aOther.mASR && mChain == aOther.mChain &&
mSeparateLeaf == aOther.mSeparateLeaf;
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
}
void ClipManager::ItemClips::CopyOutputsFrom(const ItemClips& aOther) {
mScrollId = aOther.mScrollId;
mClipChainId = aOther.mClipChainId;
}
wr::WrSpaceAndClipChain ClipManager::ItemClips::GetSpaceAndClipChain() const {
auto spaceAndClipChain = wr::RootScrollNodeWithChain();
spaceAndClipChain.space = mScrollId;
if (mClipChainId) {
spaceAndClipChain.clip_chain = mClipChainId->id;
}
return spaceAndClipChain;
}
Bug 1377187 - Rewrite the clipping code to use the new clipchain API. r=mstange The clip chain API in webrender allows us to build the clip state in WR so that it matches the gecko display list more closely. This patch throws away ScrollingLayersHelper.* and introduces ClipManager.* which pushes the clip state to WR using the new method. A quick summary of the new method is below. Each display item in gecko has a DisplayItemClipChain which is a chain of individual clips. The individual clips are defined in WR, and the clip ids for those clips are put into a WR clip chain using the new define_clip_chain API. Furthermore, each clip chain can also have a parent chain, which is used to link a DisplayItemClipChain to the parent display item's DisplayItemClipChain. This allows the WR clip state to closely match the structure of the gecko display list clip state, resulting in more correct behaviour. There are a few other major changes that are lumped into this patch and that were tricky to separate into their own patches: - The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR side all the clip ids are treated the same anyway. Trying to preserve the arbitrary distinction on the gecko side was resulting in increasingly convoluted code, with different kinds of Variant<..> types in the method signatures. It was much simpler and resulted in a bunch of code deletion to just collapse the types. - Moving the "override" mechanism from WebRenderAPI to ClipManager. The override mechanism (explained in ClipManager.h) was simplified by moving it into ClipManager, because it removed the need for tracking additional clip stack state in WebRenderAPI. MozReview-Commit-ID: GGbdFyJGprK --HG-- extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
2018-05-08 16:08:39 +03:00
} // namespace layers
} // namespace mozilla