BufferQueueProducer和surface联系

已于 2022-02-11 10:33:30 修改
阅读量3.9k 收藏 6
点赞数 1
分类专栏： Andorid Camera framework学习笔记 文章标签： p2p wpf tv
于 2021-12-04 21:07:43 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/haodada1226/article/details/121721697
版权

一、Surface::dequeueBuffer申请图形缓冲区（buffer类型为buffer_handle_t handle）

详情参考1：

android graphic(8)—surface申请GraphicBuffer过程_lyf's blog-CSDN博客

详情参考2：

Android SurfaceFlinger 学习之路(七)----创建图形缓冲区GraphicBuffer_STN_LCD的专栏-CSDN博客

总结：

1.surface先调用dequeueBuffer向BufferQueueProducer申请内存，这时会调用GraphicBufferAlloc去分配图形缓冲区，而GraphicBufferAlloc是在surfaceFlinger进程中new出来的，因此缓冲区会存在surfaceFlinger进程中，这时候就需要序列化和反序列化，将该缓冲区内存map到BufferQueue进程中；因此调用完dequeueBuffer之后，只拿到了buffer在mSlots中的下标。

2.BufferQueueProducer和surface中有大小相同的mSlots（大小为64），两者一一对应；

3. 由于BufferQueue和Surface不在同一进程，需要用requestBuffer进行内存映射，requestBuffer的核心就是：Surface传一个数组下标，然后去将BufferQueue中对应的数组下标中的GraphicBuffer对象映射到Surface中，然后保存在对应的数组中，这两个数组一一对应。

二、Surface::queueBuffer将填充好的buffer入队

    Surface::dequeueBuffer申请缓冲区，在camera result buffer时，会向缓冲区里面填充数据，这时会调用Surface::queueBuffer，也就是入队，等待消费者来拿取该buffer。

Surface::queueBuffer中的重要实现：

{  // 获取buffer在mSlots中的下标，然后进BufferQueueProducer中，去拿实际的

    int i = getSlotFromBufferLocked(buffer);

     status_t err = mGraphicBufferProducer->queueBuffer(i, input, &output);

}

BufferQueueProducer::queueBuffer：

{

     // 通过上面传递过来的idx，就可以找到绑定的GraphicBuffer

    const sp<GraphicBuffer>& graphicBuffer(mSlots[slot].mGraphicBuffer);

     // 通过

      sp<IConsumerListener> frameAvailableListener;

      frameAvailableListener = mCore->mConsumerListener;

     if (frameAvailableListener != NULL) {

           frameAvailableListener->onFrameAvailable(item);

      }    

}

我们先回过头去看看ImageReader_Init函数：

{

   sp<IGraphicBufferProducer> gbProducer;

    sp<IGraphicBufferConsumer> gbConsumer;

    BufferQueue::createBufferQueue(&gbProducer, &gbConsumer);

    sp<BufferItemConsumer> bufferConsumer;

   bufferConsumer = new BufferItemConsumer(gbConsumer, consumerUsage, maxImages,

            /*controlledByApp*/true);

}

看一下BufferItemConsumer的构造函数：

BufferItemConsumer::BufferItemConsumer(

        const sp<IGraphicBufferConsumer>& consumer, uint64_t consumerUsage,

        int bufferCount, bool controlledByApp) :

    ConsumerBase(consumer, controlledByApp){

    status_t err = mConsumer->setConsumerUsageBits(consumerUsage);

    LOG_ALWAYS_FATAL_IF(err != OK,

            "Failed to set consumer usage bits to %#" PRIx64, consumerUsage);

    if (bufferCount != DEFAULT_MAX_BUFFERS) {

        err = mConsumer->setMaxAcquiredBufferCount(bufferCount);

        LOG_ALWAYS_FATAL_IF(err != OK,

                "Failed to set max acquired buffer count to %d", bufferCount);

    }

}

再看看ConsumerBase的构造：

ConsumerBase::ConsumerBase(const sp<IGraphicBufferConsumer>& bufferQueue, bool controlledByApp) :

        mAbandoned(false),

        mConsumer(bufferQueue),

        mPrevFinalReleaseFence(Fence::NO_FENCE) {

    // Choose a name using the PID and a process-unique ID.

    mName = String8::format("unnamed-%d-%d", getpid(), createProcessUniqueId());

    // ConsumerBase是继承于ConsumerListener的，因此这里的this就是ConsumerBase本身

    wp<ConsumerListener> listener = static_cast<ConsumerListener*>(this);

    sp<IConsumerListener> proxy = new BufferQueue::ProxyConsumerListener(listener);

    status_t err = mConsumer->consumerConnect(proxy, controlledByApp)；

}

其中mConsumer->consumerConnect最终执行BufferQueueConsumer::connect，这个函数里面有一个重要的赋值：mCore->mConsumerListener = consumerListener;

也就是ConsumerBase把自己作为监听，传递给了mCore->mConsumerListener。

现在再看看BufferQueueProducer中执行的frameAvailableListener->onFrameAvailable(item)，这里就很清楚了，也就是执行ConsumerBase::onFrameAvailable

void ConsumerBase::onFrameAvailable(const BufferItem& item) {

    CB_LOGV("onFrameAvailable");

    sp<FrameAvailableListener> listener;

    { // scope for the lock

        Mutex::Autolock lock(mFrameAvailableMutex);

        listener = mFrameAvailableListener.promote();

    }

    if (listener != NULL) {

        CB_LOGV("actually calling onFrameAvailable");

        listener->onFrameAvailable(item);

    }

}

问题又来了，ConsumerBase::mFrameAvailableListener又是在何时赋值的？

继续看ImageReader_init函数：

{

    sp<BufferItemConsumer> bufferConsumer;

    bufferConsumer->setFrameAvailableListener(ctx);

}

BufferConsumer中没有实现setFrameAvailableListener方法，那直接看其父类中该方法ConsumerBase::setFrameAvailableListener的实现：

void ConsumerBase::setFrameAvailableListener(

        const wp<FrameAvailableListener>& listener) {

    CB_LOGV("setFrameAvailableListener");

    Mutex::Autolock lock(mFrameAvailableMutex);

    mFrameAvailableListener = listener;

}

综上，BufferQueueProducer::queueBuffer会将绘制完毕的buffer进行入队操作（mSlots中相应位置），再将该slot状态变成QUEUE，然后告诉监听类(ImageReader_init中new出来的JNIImageReaderContext)该buffer已经准备好了，可以取出来消费了。我们发现BufferQueueProducer和surface之间并没有实际的buffer传递，而是在传递GraphicBuffer handle，这是共享内存的一个优点，可以大大降低传输延迟。我们只要知道GraphicBuffer在BufferQueueProducer::mSlots的下标，就能找到绑定的GraphicBuffer。

三、GraphicBuffer就是常说的图形缓存区，在surfaceFlinger进程中申请的，因为GraphicBuffer对象在new时，会用GraphicBufferAllocate

GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight,

        PixelFormat inFormat, uint32_t inLayerCount, uint64_t usage, std::string requestorName)

    : GraphicBuffer() {

    mInitCheck = initWithSize(inWidth, inHeight, inFormat, inLayerCount,

            usage, std::move(requestorName));

}

status_t GraphicBuffer::initWithSize(uint32_t inWidth, uint32_t inHeight,

        PixelFormat inFormat, uint32_t inLayerCount, uint64_t inUsage,

        std::string requestorName)

{

    GraphicBufferAllocator& allocator = GraphicBufferAllocator::get();

    uint32_t outStride = 0;

    status_t err = allocator.allocate(inWidth, inHeight, inFormat, inLayerCount,

            inUsage, &handle, &outStride, mId,

            std::move(requestorName));

    if (err == NO_ERROR) {

        mBufferMapper.getTransportSize(handle, &mTransportNumFds, &mTransportNumInts);

        width = static_cast<int>(inWidth);

        height = static_cast<int>(inHeight);

        format = inFormat;

        layerCount = inLayerCount;

        usage = inUsage;

        usage_deprecated = int(usage);

        stride = static_cast<int>(outStride);

    }

    return err;

}

这里会通过get方法先获取到GraphicBufferAllocator(单例)对象，然后用其allocate方法来申请一段内存。GraphicBufferAllocator是在SurfaceFlinger中new出来的。

先看下GraphicBufferAllocator构造函数：

GraphicBufferAllocator::GraphicBufferAllocator() : mMapper(GraphicBufferMapper::getInstance()) {

     mAllocator = std::make_unique<const Gralloc3Allocator>(

            reinterpret_cast<const Gralloc3Mapper&>(mMapper.getGrallocMapper()));

    if (mAllocator->isLoaded()) {

        return;

    }

    mAllocator = std::make_unique<const Gralloc2Allocator>(

            reinterpret_cast<const Gralloc2Mapper&>(mMapper.getGrallocMapper()));

    if (mAllocator->isLoaded()) {

        return;

    }

    LOG_ALWAYS_FATAL("gralloc-allocator is missing");

}

这里面又创建了另一个核心类GraphicBufferMapper，用作映射内存，这也是个单例类，然后根据版本创建GrallocAllocator对象，只要一个对象创建成功就返回，看下GrallocAllocator的构造：

Gralloc3Allocator::Gralloc3Allocator(const Gralloc3Mapper& mapper) : mMapper(mapper) {

    mAllocator = IAllocator::getService();

    if (mAllocator == nullptr) {

        ALOGW("allocator 3.x is not supported");

        return;

    }

}

IAllocator这就是HIDL接口3.0版本

using android::hardware::graphics::allocator::V3_0::IAllocator;

好了，调用完GraphicBufferAllocator的构造后，mAllocator和mMapper对象都有了。回过头去看GraphicBufferAllocator::allocate方法的实现：

status_t GraphicBufferAllocator::allocate(uint32_t width, uint32_t height, PixelFormat format,

                                          uint32_t layerCount, uint64_t usage,

                                          buffer_handle_t* handle, uint32_t* stride,

                                          std::string requestorName) {

    return allocateHelper(width, height, format, layerCount, usage, handle, stride, requestorName,

                          true);

}

status_t GraphicBufferAllocator::allocateHelper(uint32_t width, uint32_t height, PixelFormat format,

                                                uint32_t layerCount, uint64_t usage,

                                                buffer_handle_t* handle, uint32_t* stride,

                                                std::string requestorName, bool importBuffer) {

                   

                   status_t error = mAllocator->allocate(requestorName, width, height, format, layerCount, usage,

                                          1, stride, handle, importBuffer);

                   ……

}

接下来就是用Gralloc3Allocator去分配图形缓冲区了。这里就不再往下进行分析了，至少我们知道：

Gralloc3Allocator用于分配内存；

GraphicBufferMapper用于映射内存；

详情参考：https://blog.csdn.net/qq_34211365/article/details/106782063

haodada1226
关注
  • 1
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
提供Surface管理、Buffer管理和Fence管理能力
05-01
在计算机图形学和系统编程领域，Surface管理、Buffer管理和Fence管理是至关重要的概念，尤其在高性能计算和实时渲染的应用中。以下是对这些概念的详细解释： **Surface管理：** Surface在计算机图形学中通常指的是...
图形SURFACE组件
05-01
Surface组件用于管理和传递图形和媒体的共享内存。具体场景包括了图形的送显、合成，媒体的播放、录制等。Surface的跨进程传输使用IPC传输句柄等控制结构（有拷贝），使用共享内存传递图形/媒体数据（零拷贝）。
BufferQueue学习
aaajj的专栏
01-24 927
在 https://blog.csdn.net/aaajj/article/details/93653074 https://blog.csdn.net/aaajj/article/details/102537628 里面讨论了从SurfaceFlinger中获取layer图像的一个试验 通过获取GraphicBuffer来进行处理的，在实际使用中，GraphicBuffer的管理和获取都是通过BufferQueue来进行的， 这篇博客写的很好，关于BufferQueue的...
【安卓源码】TextureView 的BufferQueue 生产者消费者机制
mike_jun的博客
03-13 1907
图像流的最常见消费者是 SurfaceFlinger，该系统服务会消耗当前可见的 Surface，并使用窗口管理器中提供的信息将它们合成到屏幕。它的作用很简单：将生成图形数据缓冲区的一方（生产方）连接到接受数据以进行显示或进一步处理的一方（消耗方）。硬件混合渲染器 HAL 则进行另一半的工作，是所有 Android 图形渲染的中心点。创建Surface的过程会涉及到与SurfaceFlinger的互动，SurfaceFlinger是一个系统级的服务，负责创建/管理/合成Surface对应的Layer。
Android13 BufferQueueProducer dequeueBuffer流程分析
liuning1985622的博客
05-05 427
BufferQueueProducer的dequeueBuffer方法是Android系统中用于从BufferQueue中获取可用的缓冲区的方法。BufferQueue是一个用于在不同线程之间传递图像数据的队列，它通常用于图像渲染和视频编解码等场景。dequeueBuffer方法的作用是从BufferQueue中获取一个可用的缓冲区，并返回该缓冲区的索引。如果没有可用的缓冲区，则该方法会阻塞，直到有可用的缓冲区为止。
Android13 BufferQueueProducer queueBuffer流程分析
最新发布
liuning1985622的博客
05-05 384
BufferQueueProducer的queueBuffer方法用于将图形缓冲区添加到队列中。当应用程序完成对图形缓冲区的绘制后，可以调用queueBuffer方法将其提交给SurfaceFlinger进行显示。将Surface进程数据传过来，然后封装成BufferItem，放入BufferQueueCore的mQueue中，再通过frameAvailableListener通知消费者去消费。
Android graphics 学习－生产者、消费者、BufferQueue介绍
热门推荐
armwind的专栏
06-18 1万+
备注:博文根据Android5.1代码分析，为个人学习笔记。如有问题，欢迎指正。 　　博文是后续理解Camera preview,recording buffer流转的基础。要不然后续Camera buffer部分不好分析。这是这几天看的笔记，也算是对BufferQueue有了新的认识，仍有许多地方需要探索。首先从整体上初步认识一下graphics组件(图片来源于Android官方文档)。
BufferQueue
qwaszx523的博客
01-09 777
 1.BufferQueue内部原理 BufferQueue是IGraphicBufferProducer服务器端的实现；所以BufferQueue会重载IGraphicBufferProducer接口中的各个虚函数queueBuffer,requesBuffer,dequeueBuffer等，该类内部还有一个mSlots[NUM_BUFFER_SLOTS]; 1.1 mSl
BaseSurfaceHolder.rar_surface
09-24
在标题"BaseSurfaceHolder.rar_surface"中，我们可以推断这是一个关于Linux系统中用于图形渲染和管理Surface对象的库或者框架的版本2.13.6。Surface在Android和一些嵌入式系统中是一个重要的概念，它代表了屏幕上一...
eglsurface.rar_surface
09-23
开发者可以通过调用EGL函数来创建、销毁、绑定和交换这些Surface，以实现高效的图形绘制和显示。 `eglsurface.c`和`eglsurface.h`这两个文件很可能是实现和声明EGLSurface相关功能的源代码和头文件。在`eglsurface....
Android13 Surface queueBuffer流程分析
liuning1985622的博客
05-05 625
Surface::queueBuffer是Android系统中Surface类的一个成员函数，用于将图像数据放入Surface的缓冲区中。它的调用地方主要包括以下几个：应用程序：应用程序可以通过Surface对象的queueBuffer函数将图像数据发送给SurfaceFlinger服务。这样，SurfaceFlinger就可以将图像数据进行合成和显示。SurfaceFlinger服务：SurfaceFlinger是Android系统中负责显示合成的服务。
Android GUI系统之SurfaceFlinger（04）应用端分析3-提交Buffer
wangdsh的博客
03-14 1949
本章节思维导图如上。主要讲述了surafce测试程序 demo的 第3步中的 提交Buffer 阶段。解锁定（最关键）并提交Buffer的过程。关键源码说明//...//1 创建surfaceflinger的客户端//2 获取surface//设置layer，layer值越大，显示层越靠前//3 获取buffer->锁定buffer->写入buffer->解锁并提交buffer//这里主要关注：申请Buff 和 提交Buff//...return 0;
AndroidQ 图形系统（4）queueBuffer函数分析
qq_34211365的博客
06-10 6615
上一篇文章分析了dequeueBuffer函数的过程，本篇接着分析queueBuffer函数，当我们需要绘制图像时，调用dequeueBuffer函数获取到可用的GraphicBuffer之后就可以开始绘制了，最常见的绘制操作就是Android上层View的draw方法了，当对GraphicBuffer的绘制操作完成之后就需要调用queueBuffer函数将这块buffer放入BufferQueue队列中并通过回调通知消费者使用这块buffer。 ...
BufferQueue/consumer/producer
Embeded system Development
11-22 2986
针对Jelly Bean版本的代码。 SurfaceFlinger是什么，这些介绍大家可以在网络上找找看，这里就直接上代码。 首先我们得了解一种常用的编程做法，生产者/消费者模型，也许都会觉得很简单，但是这里就用到了很多这些基本概念。 BufferQueue 数据都queue到这里面，前提是它是先从BufferQueue取出一个空的数据单元，称为一个buffer，实际为GraphicBu
Android画面显示流程分析(3)
lonely_fireworks的专栏
03-06 2047
Android显示画面流程讲解
ImageReader相关函数分析
haodada1226的博客
12-03 2676
一、前提知识： App中的一个surface对应SufaceFlinger中的一个layout，surface需要申请GraphicBuffer来绘制UI内容，然后交给SurfaceFlinger去合成，然后显示；ImageReader中获得的image，也就是GraphicBuffer，用于绘制surface中的UI。 应用层经常会搭配如下两个函数来获取camera数据： mImageReader = ImageReader.newInstance(1920, 1080, ImageF...
BufferQueue研究
lonely_fireworks的专栏
03-06 1990
了解BufferQueue,有助于分析应用卡顿问题。
TextureView清除摄像头最后一帧画面的原理探究
Android技术之家
06-10 1195
最近协助一个摄像头相关的项目遇到了一个有意思的问题，这里记录一下。作者：嘉伟咯链接：https://www.jianshu.com/p/a8e5c73f50a3原问题大概是使用TextureView预览摄像头,关闭摄像头之后画面会残留最后一帧,需要把他清除。我一开始使用的方式是获取Surface的Canvas去将整个画布画上黑色来实现清除画面:Canvas canvas = mPreviewSur...
EGLSurface和Surface
06-08
EGLSurface和Surface都是与Android系统窗口相关的概念，但是它们具有不同的含义和用法。 EGLSurface是EGL中的一个概念，它表示OpenGL ES绘制的目标表面，可以是一个窗口、一个像素缓冲区或者一个pixmap。在Android...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值