资源共享指的是在一个 Context 中的创建的 Texture 资源可以被其他 Context 所使用。一般来讲只有相同 share group Context 创建的 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::ExternalVkImageBacking 对接 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-R Raster 机制替代，并且在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. 参考文献
