[Android禅修之路] 解读Layer
Android禅修之路
一 前言
Layer(我看网上一些博客翻译为图元,所以后续我也用图元称号), 它是 SurfaceFlinger 中一个十分重要的人物。从 SurfaceFlinger 组成前的预备开端,就一向经过 Layer 的一些函数来完结一些操作SurfaceFlinger组成前的预处理。
例如 rebuildLayerStacks 。
并且在组成中也是有频频的调用,所以本文会详细的介绍一下图元和它内部的作业原理。
例如:
// 重建Layer调集,并核算每个Layer的可见区域的脏数据
rebuildLayerStacks();
二 Layer
2.1 Layer 的界说
首要看 Layer.h 头文件, 这个类十分长, 这儿就简略看一下它的界说
class Layer;
class Layer : public virtual compositionengine::LayerFE {
...
void onFirstRef() override;
}
class LayerFE : public virtual RefBase {
}
Layer 继承自 LayerFE,而 LayerFE 则继承自 Android 的智能指针 RefBase,关于 RefBase,当体系第一次将它的弱指针转化为强指针的时候会调用 onFirstRef,不过咱们看到 Layer 对这个函数是一个空完成,阐明详细的作业,仍是经过子类完成的。
2.2 Layer 的完成
关于 Layer 的代码完成, 这儿先简略介绍一些比较重要的类。
2.2.1 State
首要要说的便是这个结构体 State,同名的 State 还有一个是 SurfaceFlinger.h 中界说的内部类,尽管都叫 State,可是它们仍是不同的,这儿咱们看一下 Layer 中的 State
[/frameworks/native/services/surfaceflinger/Layer.h]
struct State {
Geometry active_legacy;
Geometry requested_legacy;
// z 坐标轴的值
int32_t z;
// 此图元所属的图元仓库的标识符。一个图元只能相关到一个图元仓库。
// 图元仓库是一组按 z 轴排序的图元,可与一个或多个显现器相关。在不同的显现器上运用相同的 layerStack 是完成镜像的一种办法
uint32_t layerStack;
uint8_t flags;
uint8_t reserved[2];
// 该图元的序列号,每次图元的特点产生改动时,这个序列号都需求自增
int32_t sequence;
bool modified;
...
// 数据空间,仅 BufferStateLayer 和 ColorLayer 运用
ui::Dataspace dataspace;
// 此点下方的字段仅由 BufferStateLayer 运用
Geometry active;
std::list<std::shared_ptr<SyncPoint>> mLocalSyncPoints;
...
};
关于 State,这儿列举出来一些常常用到的,比方决议图元顺序的Z轴坐标,决议图元显现在哪个显现器的 layerStack 等等。
再看一下 Layer 中的两个 State 变量
- mCurrentState:当时图元的 State
- mDrawingState:前次制作图元时的 State
这两个变量代表了图元的两个状况,一个是当时的状况,一个是前次制作的状况,由于图元的状况是能够更改的,假如当时的状况和前次制作的状况不一致,那么就阐明状况产生了改动。
2.2.1 Layer 的结构函数
[/frameworks/native/services/surfaceflinger/Layer.h]
Layer::Layer(const LayerCreationArgs& args)
: mFlinger(args.flinger),
mName(args.name),
mClientRef(args.client),
mWindowType(args.metadata.getInt32(METADATA_WINDOW_TYPE, 0)) {
mCurrentCrop.makeInvalid();
uint32_t layerFlags = 0;
if (args.flags & ISurfaceComposerClient::eHidden) layerFlags |= layer_state_t::eLayerHidden;
if (args.flags & ISurfaceComposerClient::eOpaque) layerFlags |= layer_state_t::eLayerOpaque;
if (args.flags & ISurfaceComposerClient::eSecure) layerFlags |= layer_state_t::eLayerSecure;
mTransactionName = String8("TX - ") + mName;
// 给 mCurrentState 成员变量的赋值
mCurrentState.active_legacy.w = args.w;
mCurrentState.active_legacy.h = args.h;
mCurrentState.flags = layerFlags;
...
//将当时状况赋值给制作状况
mDrawingState = mCurrentState;
CompositorTiming compositorTiming;
args.flinger->getCompositorTiming(&compositorTiming);
mFrameEventHistory.initializeCompositorTiming(compositorTiming);
mFrameTracker.setDisplayRefreshPeriod(compositorTiming.interval);
mSchedulerLayerHandle = mFlinger->mScheduler->registerLayer(mName.c_str(), mWindowType);
// 然后回调 SurfaceFlinger 的 onLayerCreated
mFlinger->onLayerCreated();
}
Layer 的结构函数的参数是 LayerCreationArgs,这是一个封装好的结构体,它里面保存的是结构函数真正需求的参数。
在结构函数中,会做一些变量的初始化,然后给 mCurrentState 里的一些特点赋值,并将 mCurrentState 赋值给 mDrawingState,也便是说到现在方位,图元当时的状况便是制作状况。之后假如再对图元进行修改,就会修改到 mCurrentState 中,这样两者就产生了差异,直到下次制作,又让两者达到一致。
2.2.2 LayerCreationArgs
接下来再看一下 LayerCreationArgs 这个类, 看名字也知道它是图元创立时运用到的参数, 它将图元创立时需求的参数进行的封装
[/frameworks/native/services/surfaceflinger/Layer.h]
struct LayerCreationArgs {
LayerCreationArgs(SurfaceFlinger* flinger, const sp<Client>& client, const String8& name,
uint32_t w, uint32_t h, uint32_t flags, LayerMetadata metadata)
: flinger(flinger), client(client), name(name), w(w), h(h), flags(flags),
metadata(std::move(metadata)) {}
SurfaceFlinger* flinger;
const sp<Client>& client;
const String8& name;
uint32_t w;
uint32_t h;
uint32_t flags;
LayerMetadata metadata;
};
这儿面的参数都比较简略,仅有一个需求注意的是这个 Client,它是界说在frameworks/native/services/surfaceflinger/Client.h
,这个 Client 在 SurfaceFlinger 中代表使用端(App端)。
2.2.3 SyncPoint
SyncPoint 是界说在 Layer.h 头文件中的一个内部类,翻译过来便是同步点
class SyncPoint {
public:
explicit SyncPoint(uint64_t frameNumber, wp<Layer> requestedSyncLayer)
: mFrameNumber(frameNumber),
mFrameIsAvailable(false),
mTransactionIsApplied(false),
mRequestedSyncLayer(requestedSyncLayer) {}
uint64_t getFrameNumber() const { return mFrameNumber; }
bool frameIsAvailable() const { return mFrameIsAvailable; }
void setFrameAvailable() { mFrameIsAvailable = true; }
bool transactionIsApplied() const { return mTransactionIsApplied; }
void setTransactionApplied() { mTransactionIsApplied = true; }
// wp 是 Android native 中的智能弱指针,sp 是Android native 中的智能强指针
// promote 其实便是将智能弱指针转化未智能强指针
sp<Layer> getRequestedSyncLayer() { return mRequestedSyncLayer.promote(); }
private:
const uint64_t mFrameNumber;
std::atomic<bool> mFrameIsAvailable;
std::atomic<bool> mTransactionIsApplied;
wp<Layer> mRequestedSyncLayer;
};
// 界说在 Layer.h 中的关于 SyncPoint 个目标
Mutex mLocalSyncPointMutex; //锁
// 一个 SyncPoint 的列表
std::list<std::shared_ptr<SyncPoint>> mLocalSyncPoints;
// 使用业务时将宣布信号然后移除的同步点
std::list<std::shared_ptr<SyncPoint>> mRemoteSyncPoints;
同步点,当正确的帧坐落队列的头部时将宣布信号,并在帧被锁定后丢掉。受mLocalSyncPointMutex保护
2.3 LayerFE
接下来再看 LayerFE 的界说,
[frameworks/native/services/surfaceflinger/CompositionEngine/include/compositionengine/LayerFE.h]
class LayerFE : public virtual RefBase {
public:
// 更新与显现无关的组成状况。假如 includeGeometry 为 false ,则能够越过 geometry 状况
virtual void latchCompositionState(LayerFECompositionState&, bool includeGeometry) const = 0;
// 在 Layer 显现后调用以更新 Fence
virtual void onLayerDisplayed(const sp<Fence>&) = 0;
// debug name
virtual const char* getDebugName() const = 0;
};
关于 LayerFE , 根据官方的说法, 它是一个接口,这个接口界说了 CompositionEngine 组成引擎向前端层宣布请求的函数。
三 组成前的Layer
接下来咱们先依照之前 SurfaceFlinger 的组成流程,来看 Layer 的作业原理,首要是组成前 Layer 做了什么。详细的 SurfaceFlinger 的组成流程能够检查SurfaceFlinger的组成总览
3.1 notifyAvailableFrames
首要是 handleTransactionLocked 中的 notifyAvailableFrames,这个函数在 Layer.h 中是一个空完成,看来又是由它的子类处理的。可是根据我的检查,真正完成了这个函数的子类只有 BufferLayer。
[frameworks/native/services/surfaceflinger/Layer.h]
virtual void notifyAvailableFrames() {}
3.1.1 BufferLayer::notifyAvailableFrames
[/frameworks/native/services/surfaceflinger/BufferLayer.cpp]
void BufferLayer::notifyAvailableFrames() {
const auto headFrameNumber = getHeadFrameNumber();
const bool headFenceSignaled = fenceHasSignaled();
const bool presentTimeIsCurrent = framePresentTimeIsCurrent();
Mutex::Autolock lock(mLocalSyncPointMutex);
// 遍历 mLocalSyncPoints,这个是一个同步点的调集[2.2.3]
for (auto& point : mLocalSyncPoints) {
// 假如头部帧的序号大于同步点中帧的序号,并且头部帧现已发送过Fence信号
// Fence 信号是用于软硬件间同步的
if (headFrameNumber >= point->getFrameNumber() && headFenceSignaled &&
presentTimeIsCurrent) {
// 告诉同步点,将同步点中的 mFrameIsAvailable 设置为 true,见 [2.2.3]
point->setFrameAvailable();
// 从同步点获取需求同步的图元,并更新它的业务标志
sp<Layer> requestedSyncLayer = point->getRequestedSyncLayer();
if (requestedSyncLayer) {
// 更新业务标志以保证使用层的挂起业务,完成在 Layer.cpp 中
requestedSyncLayer->setTransactionFlags(eTransactionNeeded);
}
}
}
}
3.2 getTransactionFlags
接下来是 handleTransactionLocked 中的 getTransactionFlags,它直接回来了 Layer 中的 mTransactionFlags 。忘记 handleTransactionLocked 能够看SurfaceFlinger组成前的预处理。
[frameworks/native/services/surfaceflinger/Layer.h]
uint32_t getTransactionFlags() const { return mTransactionFlags; }
3.3 doTransaction
doTransaction 便是处理业务,Layer 会根据当时的图元哪些特点产生了改动,来决议详细应该怎么做,在介绍之前Layer 中 State 结构体的时候,看到了一个成员变量 sequence,这个序列号便是用来记录图元特点产生改动的。
[frameworks/native/services/surfaceflinger/Layer.cpp]
uint32_t Layer::doTransaction(uint32_t flags) {
... // 前面会进行一些特点判别
State c = getCurrentState();
// doTransactionResize 判别当时图元的 size 是否产生了改动
flags = doTransactionResize(flags, &c);
// 获取制作时的状况
const State& s(getDrawingState());
// 假如当时的的状况和制作时的状况的活动区域不相同,那么就需求从头核算可见区域
if (getActiveGeometry(c) != getActiveGeometry(s)) {
// 需求从头核算可见区域,假如活动区域 active_legacy 不一致,则需求从头核算可见区域
flags |= Layer::eVisibleRegion;
}
// 假如当时状况的序列号和制作时的序列号不一致,那么当时的图元特点必定产生了改变
if (c.sequence != s.sequence) {
// 从头核算可见区域
flags |= eVisibleRegion;
// 内容脏了,即当时图元存在脏区域,需求从头组成制作等操作
this->contentDirty = true;
...
}
...
// 提交业务
commitTransaction(c);
mCurrentState.callbackHandles = {};
return flags;
}
doTransaction 这个函数的逻辑很简略
- 先判别活动区域是否产生了改变
- 再判别图元的特点是否产生了改变
- 最终提交业务
3.3.1 commitTransaction
再来看一下提交业务的逻辑,原来便是将当时的图元的状况赋值给制作图元的状况,这样状况就同步了,然后比及下一轮状况产生改动时,再重复之前的动作即可。
void Layer::commitTransaction(const State& stateToCommit) {
mDrawingState = stateToCommit;
}
关于序列号 sequence 的改动,这儿就不再扩展了,简略来说,便是当调用图元 Layer 的 set 之类的办法时,sequence 就会自增。
最终关于 doTransaction 需求说一点的是,它的函数传入的是一个 int 值 flag,回来的也是一个 int 值,当时这个值在之前判别图元特点时现已产生了改动,而它的回来值也决议了后续 SurfaceFlinger 组成的一些操作。这儿能够回顾一下SurfaceFlinger组成前的预处理
四 Layer 的子类
Layer 表示的是 Android 体系中的图元, 那么关于 Layer 的子类, 则是详细的图元操作的封装。Layer 的子类主要有三个
- ColorLayer
- BufferLayer
- BufferStateLayer
3.1 ColorLayer
ColorLayer 即色彩图元, 它算是 Layer 的几个子类中最简略的一个子类了, 不过麻雀虽小, 五脏俱全. 经过检查 ColorLayer , 咱们基本能够看到图元的一些根底操作
3.1.1 ColorLayer 的界说
首要仍是先看 ColorLayer.h 头文件
[frameworks/native/services/surfaceflinger/ColorLayer.h]
class ColorLayer : public Layer {
public:
// 结构函数和析构函数
explicit ColorLayer(const LayerCreationArgs&);
~ColorLayer() override;
//
std::shared_ptr<compositionengine::Layer> getCompositionLayer() const override;
// Layer 的类型: ColorLayer
virtual const char* getTypeId() const { return "ColorLayer"; }
// 可见状况
bool isVisible() const override;
// 色彩
bool setColor(const half3& color) override;
// 数据空间
bool setDataspace(ui::Dataspace dataspace) override;
// 将帧数据设置到 HWComposer 中
void setPerFrameData(const sp<const DisplayDevice>& display, const ui::Transform& transform,
const Rect& viewport, int32_t supportedPerFrameMetadata,
const ui::Dataspace targetDataspace) override;
// 提交操作
void commitTransaction(const State& stateToCommit) override;
// 组成前的预处理
// 在 ColorLayer 中直接回来了 fasle , 没有做任何逻辑, 由于 ColorLayer 没有组成前预处理
bool onPreComposition(nsecs_t /*refreshStartTime*/) override { return false; }
protected:
virtual bool prepareClientLayer(const RenderArea& renderArea, const Region& clip,
bool useIdentityTransform, Region& clearRegion,
const bool supportProtectedContent,
renderengine::LayerSettings& layer);
private:
std::shared_ptr<compositionengine::Layer> mCompositionLayer;
};
3.1.2 ColorLayer 的完成
3.1.2.1 结构函数
ColorLayer::ColorLayer(const LayerCreationArgs& args)
: Layer(args),
mCompositionLayer{mFlinger->getCompositionEngine().createLayer(
compositionengine::LayerCreationArgs{this})} {}
ColorLayer 中结构时, 调用了父类 Layer 的结构函数, 然后还创立了一个 mCompositionLayer 目标
3.1.2.2 commitTransaction
最终再来看一下 commitTransaction 的 ,它其实调用的也是 Layer 的 commitTransaction (见3.3.1)。
void ColorLayer::commitTransaction(const State& stateToCommit) {
Layer::commitTransaction(stateToCommit);
mCurrentDataSpace = mDrawingState.dataspace;
}
3.1.2.3 prepareClientLayer
再来说说 prepareClientLayer 这个函数,它会在 SurfaceFlinger 的组成中调用,概况能够检查 SurfaceFlinger组成中的作业 中的 3.2 doComposeSurfaces 的第二部分。
bool ColorLayer::prepareClientLayer(const RenderArea& renderArea, const Region& clip,
bool useIdentityTransform, Region& clearRegion,
const bool supportProtectedContent,
renderengine::LayerSettings& layer) {
Layer::prepareClientLayer(renderArea, clip, useIdentityTransform, clearRegion,
supportProtectedContent, layer);
half4 color(getColor());
half3 solidColor(color.r, color.g, color.b);
layer.source.solidColor = solidColor;
return true;
}
3.1.2.3 setPerFrameData
setPerFrameData 的效果是为每一层图元设置需求显现的数据。所以它做的大致是如下几件事情
- 设置可见区域
- 设置输出图元
- 设置图元的组成方法为色彩图元
- 设置数据空间
- 设置数据(即色彩)
void ColorLayer::setPerFrameData(const sp<const DisplayDevice>& display,
const ui::Transform& transform, const Rect& viewport,
int32_t /* supportedPerFrameMetadata */,
const ui::Dataspace targetDataspace) {
// 处理可见区域
Region visible = transform.transform(visibleRegion.intersect(viewport));
// 找到需求输出的显现图元
const auto outputLayer = findOutputLayerForDisplay(display);
// hwcLayer
auto& hwcLayer = (*outputLayer->getState().hwc).hwcLayer;
//
auto error = hwcLayer->setVisibleRegion(visible);
if (error != HWC2::Error::None) {
visible.dump(LOG_TAG);
}
outputLayer->editState().visibleRegion = visible;
// 设置组成方法为色彩图元
setCompositionType(display, Hwc2::IComposerClient::Composition::SOLID_COLOR);
const ui::Dataspace dataspace =
isColorSpaceAgnostic() && targetDataspace != ui::Dataspace::UNKNOWN ? targetDataspace
// 设置数据空间
error = hwcLayer->setDataspace(dataspace);
auto& layerCompositionState = getCompositionLayer()->editState().frontEnd;
layerCompositionState.dataspace = mCurrentDataSpace;
half4 color = getColor();
error = hwcLayer->setColor({static_cast<uint8_t>(std::round(255.0f * color.r)),
static_cast<uint8_t>(std::round(255.0f * color.g)),
static_cast<uint8_t>(std::round(255.0f * color.b)), 255});
layerCompositionState.color = {static_cast<uint8_t>(std::round(255.0f * color.r)),
static_cast<uint8_t>(std::round(255.0f * color.g)),
static_cast<uint8_t>(std::round(255.0f * color.b)), 255};
// Clear out the transform, because it doesn't make sense absent a source buffer
error = hwcLayer->setTransform(HWC2::Transform::None);
outputLayer->editState().bufferTransform = static_cast<Hwc2::Transform>(0);
error = hwcLayer->setColorTransform(getColorTransform());
layerCompositionState.colorTransform = getColorTransform();
error = hwcLayer->setSurfaceDamage(surfaceDamageRegion);
layerCompositionState.surfaceDamage = surfaceDamageRegion;
}
3.2 BufferLayer
3.2.1 BufferLayer 的界说
比较于 ColorLayer , BufferLayer 中包括的函数多了许多, 这也是由于 BufferLayer 的处理比简略色彩图元的处理要复杂许多, 不过后续咱们需求关注的, 仍是从父类中继承来的那些公共的函数
class BufferLayer : public Layer {
public:
explicit BufferLayer(const LayerCreationArgs& args);
~BufferLayer() override;
public:
std::shared_ptr<compositionengine::Layer> getCompositionLayer() const override;
// 假如咱们在这个帧中收到一个新的缓冲区,咱们将把它的表脏区域传递给 hardware composer (后续简称hwc)
// 不然,咱们有必要发送一个包括一个空 rect 的区域
void useSurfaceDamage() override;
void useEmptyDamage() override;
// 图元的类型: BufferLayer
const char* getTypeId() const override { return "BufferLayer"; }
// 是否是不透明的
bool isOpaque(const Layer::State& s) const override;
// 是否可见
bool isVisible() const override;
// isProtected - true if the layer may contain protected content in the
// GRALLOC_USAGE_PROTECTED sense.
// 是否包括受保护的内容(在 GRALLOC_USAGE_PROTECTED 区域), true 表示包括
bool isProtected() const override;
// 内容是否是固定巨细, true 表示是的
bool isFixedSize() const override;
bool usesSourceCrop() const override;
bool isHdrY410() const override;
// 设置帧数据
void setPerFrameData(const sp<const DisplayDevice>& display, const ui::Transform& transform,
const Rect& viewport, int32_t supportedPerFrameMetadata,
const ui::Dataspace targetDataspace) override;
// 组成前预处理
bool onPreComposition(nsecs_t refreshStartTime) override;
// 组成后的处理
bool onPostComposition(const std::optional<DisplayId>& displayId,
const std::shared_ptr<FenceTime>& glDoneFence,
const std::shared_ptr<FenceTime>& presentFence,
const CompositorTiming& compositorTiming) override;
// latchBuffer-每次从头制作屏幕时调用,并回来是否需求从头核算可见区域。
// 这是一个适当重的操作,所以只在需求时才设置)。
// 通常,这用于确认 Surface 的内容或巨细是否已更改
bool latchBuffer(bool& recomputeVisibleRegions, nsecs_t latchTime) override;
bool isBufferLatched() const override { return mRefreshPending; }
void notifyAvailableFrames() override;
bool hasReadyFrame() const override;
// 回来当时缩放模式, 假如设置了mOverrideScalingMode 则回来 mOverrideScalingMode
uint32_t getEffectiveScalingMode() const override;
// -----------------------------------------------------------------------
// 有必要由派生类完成的函数
// -----------------------------------------------------------------------
...
}
3.2.2 BufferLayer 的完成
3.2.2.1 prepareClientLayer
相同,咱们也看下 BufferLayer 的 prepareClientLayer 是怎么完成的。它和 ColorLayer 一样,会在 SurfaceFlinger 的组成中调用,概况能够检查 SurfaceFlinger组成中的作业 中的 3.2 doComposeSurfaces 的第二部分。
bool BufferLayer::prepareClientLayer(const RenderArea& renderArea, const Region& clip,
bool useIdentityTransform, Region& clearRegion,
const bool supportProtectedContent,
renderengine::LayerSettings& layer) {
Layer::prepareClientLayer(renderArea, clip, useIdentityTransform, clearRegion,
supportProtectedContent, layer);
if (CC_UNLIKELY(mActiveBuffer == 0)) {
//纹路还没有被创立,这个图元实际上从来没有被制作。这在SurfaceView中常常产生,由于WindowManager不知道客户端什么时候第一次制作
// 如下下层没有任何东西, 就把屏幕制作成黑色, 不然就越过这个更新
// 遍历底层
Region under;
bool finished = false;
mFlinger->mDrawingState.traverseInZOrder([&](Layer* layer) {
if (finished || layer == static_cast<BufferLayer const*>(this)) {
finished = true;
return;
}
under.orSelf(layer->visibleRegion);
});
// 假如没有Layer在这个图元的底部, 就忽略这个图元的空地
Region holes(clip.subtract(under));
if (!holes.isEmpty()) {
clearRegion.orSelf(holes);
}
return false;
}
// DRM处理, 假如图元是安全内存就直接制作一块黑色. 主要是针对数字版权
bool blackOutLayer =
(isProtected() && !supportProtectedContent) || (isSecure() && !renderArea.isSecure());
const State& s(getDrawingState());
if (!blackOutLayer) {
layer.source.buffer.buffer = mActiveBuffer;
layer.source.buffer.isOpaque = isOpaque(s);
layer.source.buffer.fence = mActiveBufferFence;
layer.source.buffer.textureName = mTextureName;
layer.source.buffer.usePremultipliedAlpha = getPremultipledAlpha();
layer.source.buffer.isY410BT2020 = isHdrY410();
// TODO: we could be more subtle with isFixedSize()
const bool useFiltering = needsFiltering(renderArea.getDisplayDevice()) ||
renderArea.needsFiltering() || isFixedSize();
// 查询咱们当时过滤模式下的纹路矩阵
float textureMatrix[16];
setFilteringEnabled(useFiltering);
getDrawingTransformMatrix(textureMatrix);
// 显现器的反正屏切换, 保证缓冲区和本机的显现方向一致
if (getTransformToDisplayInverse()) {
// 下面的代码将主显现的反改换使用到纹路改换
uint32_t transform = DisplayDevice::getPrimaryDisplayOrientationTransform();
mat4 tr = inverseOrientation(transform);
// 保证无论父转化怎么,这个缓冲区总是从本机显现方向转化为显现方向。
// 例如,在一个相机的情况下,缓冲区保持在本机方向,咱们希望像素总是垂直的
sp<Layer> p = mDrawingParent.promote();
if (p != nullptr) {
const auto parentTransform = p->getTransform();
tr = tr * inverseOrientation(parentTransform.getOrientation());
}
// 最终将改换使用到原始纹路矩阵中
const mat4 texTransform(mat4(static_cast<const float*>(textureMatrix)) * tr);
memcpy(textureMatrix, texTransform.asArray(), sizeof(textureMatrix));
}
const Rect win{getBounds()};
float bufferWidth = getBufferSize(s).getWidth();
float bufferHeight = getBufferSize(s).getHeight();
// 假如缓冲区没有设置帧, 就设置一个尺度为[0,0,-1,-1], 并忽略这个缓冲区
if (!getBufferSize(s).isValid()) {
bufferWidth = float(win.right) - float(win.left);
bufferHeight = float(win.bottom) - float(win.top);
}
const float scaleHeight = (float(win.bottom) - float(win.top)) / bufferHeight;
const float scaleWidth = (float(win.right) - float(win.left)) / bufferWidth;
const float translateY = float(win.top) / bufferHeight;
const float translateX = float(win.left) / bufferWidth;
//由于GLConsumer和OpenGL的约定, 翻转y坐标,
mat4 tr = mat4::translate(vec4(.5, .5, 0, 1)) * mat4::scale(vec4(1, -1, 1, 1)) *
mat4::translate(vec4(-.5, -.5, 0, 1)) *
mat4::translate(vec4(translateX, translateY, 0, 1)) *
mat4::scale(vec4(scaleWidth, scaleHeight, 1.0, 1.0));
layer.source.buffer.useTextureFiltering = useFiltering;
layer.source.buffer.textureTransform = mat4(static_cast<const float*>(textureMatrix)) * tr;
} else {
// 假如图元被涂黑,强制alpha值为1,这样咱们就能够画一个黑色图元
layer.source.buffer.buffer = nullptr;
layer.alpha = 1.0;
}
return true;
}
3.2.2.1 onPreComposition
在 ColorLayer 中, 组成前的预处理没有任何作业. 可是关于 BufferLayer , 则会预先做一些事情,onPreComposition 是 组成前的预处理作业,它会在SurfaceFlinger的组成前调用,详细的方位能够检查SurfaceFlinger组成前的预处理 中的二 preComposition。
bool BufferLayer::onPreComposition(nsecs_t refreshStartTime) {
if (mBufferLatched) {
Mutex::Autolock lock(mFrameEventHistoryMutex);
// 将当时的帧数添加到 mFrameEventHistory
mFrameEventHistory.addPreComposition(mCurrentFrameNumber, refreshStartTime);
}
mRefreshPending = false;
// 判别当时是否还有现已预备好的帧需求处理
return hasReadyFrame();
}
hasReadyFrame
bool BufferLayer::hasReadyFrame() const {
// 在这三种情况下是需求继续处理的
// 1. hasFrameUpdate 为 true , 即当时状况产生了改动, 并且还有提交来的 buffer
// 2. SidebandStream 产生了改动
// 3. 当时是自动刷新模式
return hasFrameUpdate() || getSidebandStreamChanged() || getAutoRefresh();
}
3.2.2.2 setPerFrameData
compositionengine::OutputLayer* Layer::findOutputLayerForDisplay(
const sp<const DisplayDevice>& display) const {
// DisplayDevice 的 getCompositionDisplay 获取到它的成员变量 mCompositionDisplay
// const std::shared_ptr<compositionengine::Display> mCompositionDisplay;
// getOutputLayerForLayer 拿到的是一个
return display->getCompositionDisplay()->getOutputLayerForLayer(getCompositionLayer().get());
}
到此,关于 Layer 的介绍现已算是完结了一半了。
为什么我要说是一半呢?由于现在还仅仅粗略的介绍了 Layer 组成的相关操作,而它是怎么来的,整体上的流程是怎样的还没有阐明,下面,我就经过 Activity 开端,结合此篇 Layer 详细的函数,来详细阐明 Layer 的界面显现中的效果。