资源共享指的是在一个 Context 中的创建的 Texture 资源可以被其他 Context 所使用。一般来讲只有相同share groupContext 创建的 Texture 才可以被共享，而 Chromium 设计了一套允许不同share group并且跨进程的 Texture 共享机制。
Chromium 中有新旧两套共享 Texture 的机制，一套是 Mailbox 机制，一套是 SharedImage 机制。
1.Mailbox 机制
Mailbox 机制由CHROMIUM_texture_mailbox扩展提供，它定义了一种在不同Context之间共享 Texture 对象中的图片数据的方式，不管这些Context是否处于相同的share group。
它定义了2个方法：
glProduceTextureDirectCHROMIUM方法传入一个当前Context中已经存在的texture对象，然后返回一个指向该texture的mailbox。后续可以在其他的Context中使用glCreateAndConsumeTextureCHROMIUM方法通过这个mailbox创建一个新的texture对象，新对象存在于新的 Context 中。结合 Command Buffer，可以实现跨进程共享Texture的效果。
Mailbox类本身是一个定长的字节数组，作为资源的唯一标识符，默认是16字节，系统全局唯一，可以跨进程。
Mailbox 机制使用起来非常方便，但是它对 service 端的运行环境依赖非常严重，比如要求 service 端的所有 Context 都必须属于相同 share group，这导致service端在某些平台上需要使用Virtual Context或者很多的同步机制才能实现，而这些会导致性能损失。再加上这种机制基于GL，无法很好的支持Vulkan，因此 Mailbox 机制已经被标记为deprecated，在当前的 Chromium 中只有 media 模块还在使用。新代码应该使用SharedImage机制。
2.SharedImage 机制
ShareImage 机制从2018年开始引入，设计用来取代 Mailbox 机制并且支持 Vulkan。它引入了一套 client 端的 SharedImage 接口以及一个新的GL扩展CHROMIUM_shared_image。
主要接口为SharedImageInterface，用来创建 shared images，定义如下：
这是一个 client 端的接口，可以通过gpu::GpuChannelHost来获取到。对它的调用会通过 IPC 接口发送到 service 端，service 端会使用合适的机制来存储 SharedImage 的数据，比如GL Texture，GMB(GpuMemoryBuffer)等。
CreateSharedImage方法创建一个新的 SharedImage 并返回一个 mailbox 指向它。UpdateSharedImage方法更新指定的 SharedImage 的属性。DestroySharedImage销毁指定的 SharedImage，释放相关内存。
在client端，通过CHROMIUM_shared_image扩展提供的方法来读写 SharedImage 数据。Mailbox机制中CHROMIUM_texture_mailbox扩展提供的方法也可以用来访问SharedImage，因为SharedImage机制兼容了Mailbox机制。但应该尽量比避免这样使用，因为 Mailbox 机制已经过时了。在 service 端也可以用这种方法来访问 ShareImage。
在servcie端，SharedImage实现了大概3类存储机制，分别为 GLTexture/EGLImage，GMB 和 VulkanImage，这三大类又被抽象为了很多种小类。下面这些都是SharedImage可能的存储后端：
其中gpu::SharedImageBackingGLTexture使用 GL Texture 来存储 SharedImage 数据。gpu::SharedImageBackingEglImage使用 EGLImage 来存储数据。gpu::SharedImageBackingAHB仅用于 Android 平台，使用 Android 提供的 AHardwareBuffer 来存储数据。gpu::ExternalVkImage服务器托管网Backing对接 Vulkan。gpu::SharedImageBackingGLImage比较特殊，它表示使用gpu::GLImage类来进行存储，gpu::GLImage又抽象了不同的存储后端，最服务器托管网终也可能使用 GL Texture。
SharedImage 机制本质上抽象了 GPU 的数据存储能力。即允许应用直接把数据存储到 GPU （GPU 能访问到的内存）中，以及直接从 GPU 中读取数据，并且允许跨过shared group边界。理解了这一点，应该比较容易想到哪些场景可以使用 SharedImage 机制，下面这些是 Chromium 中使用 SharedImage 机制的一些场景：
- CC模块： 先将画面 Raster 到 SharedImage，然后再发送给 Viz 进行合成。
- OffscreenCanvas： 先将 Canvas 的内容 Raster 到 SharedImage，然后再发送给 Viz 进行合成。
- 图片处理/渲染： 一个线程将图片解码到 GPU 中，另一个线程使用 GPU 来修改或者渲染图片。
- 视频播放： 一个线程将视频解码到 GPU 中，另一个线程来渲染。
下面介绍2个操作 ShareImage 的扩展。需要注意的是在使用这些扩展方法之前都先要有一个指向 SharedImage 的 mailbox，可以使用SharedImageInterface接口创建，也可以是从其他地方传过来。
4.CHROMIUM_shared_image 扩展
CHROMIUM_SHARED_IMAGE扩展定义了以下4个方法:
glCreateAndTexStorage2DSharedImageCHROMIUM*方法根据传入的mailbox创建一个新的 Texture 对象。然后应用可以使用glBeginSharedImageAccessDirectCHROMIUM方法获取读/写texture对象的权限，然后使用常规的读写texture的GL命令访问texture的内容，比如glGetTexImage，glReadPixels，glTexImage2D等或者使用skia来间接访问texture的内容。操作结束之后，调用glEndSharedImageAccessDirectCHROMIUM方法释放权限。
这些接口用于GPU-R机制下的 Raster，这种 Raster 机制已经被OOP-RRaster 机制替代，并且在2022年2月份被移除，这里只用于演示旧版本GPU-R方式的 Raster：
5.CHROMIUM_raster_transport
glBeginRasterCHROMIUM方法表示要开始执行 Raster 操作了，Raster的结果存放到传入的mailbox对应的 SharedImage 中。glRasterCHROMIUM将cc::DisplayItemList序列化后发送到service端。参数raster_shm_id指向存储cc::DisplayItemList序列化数据的共享内存。glEndRasterCHROMIUM结束 Raster 操作。
这些接口用于OOP-R(Out-Of-Process Raster)机制下的 Raster。关于 OOP-R 见后续文档， 下面的代码演示使用 OOP-R 接口创建 SharedImage：
6.SharedImage 架构设计
SharedImage 被设计用于多进程架构，Client 端可以有多个，比如 Browser/Render/Gpu 进程都可以作为 Client 端，Service 端只能有一个，它运行在 Gpu 进程中。Client 和 Servcie 通过 IPC 进行通信。Client 端的接口主要包括 SharedImageInterface 和 2 个扩展。Service 端将数据存储在基于不同技术实现的 SharedImageBacking 中。
7.SharedImage 实现原理
8. 总结
在当前的 Chromium 中，Mailbox 机制是建立在 SharedImage 机制之上的。旧的 Mailbox 机制的接口正在被废弃（Mailbox 类本身并不会被废弃），在新的代码中应该使用新的 SharedImage 接口。
在所有需要“分阶段”渲染的场合都可以使用 SharedImage 机制，在需要从 GPU 读取数据的场合也可以使用 SharedImage 机制。SharedImage 机制只提供内存的管理，应用可以使用常规的读写GPU数据的方式来读写SharedImage中的数据。
9. 参考文献
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
相关推荐: Nginx网站服务
Nginx介绍www.cpdd.comwww.accp.com目录 Nginx介绍 Nginx优点 Nginx和apache的区别 下载和安装 检查、启动、重启、停止、nginx服务 Nginx配置文件 http配置 访问状态统计配置 基于授权的访问控制 基于客户端的访问控制 基于域名的Nginx虚拟主机 基于IP的Ng…
