基本上，它们使用另一个过程将它们全部粘合到GUI中。
Google Chrome创建了三种不同类型的进程：浏览器、渲染器和插件。

**浏览器：**只有一个浏览器进程，它管理浏览器的选项卡、窗口和“chrome”。此进程还处理与磁盘、网络、用户输入和显示的所有交互，但它不会尝试解析或呈现来自Web的任何内容。
**渲染器：**浏览器进程创建许多渲染器进程，每个进程负责渲染网页。渲染器进程包含处理HTML、JavaScript、CSS、图像等的所有复杂逻辑。Chrome使用开源WebKit渲染引擎实现这一点，苹果的Safari网络浏览器也使用该引擎。每个渲染器进程都在沙箱中运行，这意味着它几乎无法直接访问磁盘、网络或显示器。与网络应用程序的所有交互，包括用户输入事件和屏幕绘制，都必须通过浏览器进程。这使得浏览器进程可以监控渲染器的可疑活动，如果怀疑发生了漏洞，则会将其杀死。
**插件：**浏览器进程还为正在使用的每种插件创建一个进程，如Flash、Quicktime或Adobe Reader。这些进程只包含插件本身，沿着一些粘合代码，使它们能够与浏览器和呈现器交互。

来源：Chromium Blog: Multi-process Architecture

在这种情况下，基本设计很有趣。
下面是相关的design documents，特别是multi-process architecture部分。
体系结构概述：

我只是给出了第一个答案（解释“浏览器”与“渲染器”与“插件”的答案），这似乎是最完整的，对我来说很有意义。
我唯一要补充的是关于为什么谷歌的设计是这样的一些评论，并给予一个关于为什么它总是我的第一选择的整体/日常浏览器的意见。（但我意识到，如何（而不是为什么）被问到的问题。）
设计成各个组件在单独的进程中有它们的代码，允许操作系统“内存保护”进程，防止意外（或故意）以非显式设计的方式修改彼此。
在这种设计中，能够读取和写入共享数据的仅有部分是被设计成需要访问该数据的那些部分，并且允许控制该访问是仅仅“读”访问还是“读”和“写”访问等。并且，由于那些访问控制在硬件中实现，因此它们是不能违反访问规则的可靠保证。来自其他作者和公司的插件和扩展在单独的选项卡/进程中运行，不能彼此中断。
这样的设计可以最大限度地减少更改某些原本不应更改的代码或数据的机会，这是出于安全原因，并且可以使代码更可靠，错误更少。
对我来说，谷歌拥有如此复杂的设计这一事实很好地证明了这样一个事实，即谷歌似乎对这些概念有着出色的把握，并打造了一款上级的产品。（也就是说，作为一个网页开发者，我们仍然必须在多个浏览器上测试我们的网页代码。已经存在了很长时间并且拥有一组优秀的与web开发者相关的“附加组件”对于某些任务仍然具有一些优势）。
但是，对于浏览器的日常使用，对于几乎所有的任务，Chrome浏览器已经成为我的首选。（这只是我的意见，当然，YMMV。）

渲染一个网页的大部分工作是弄清楚事情的确切位置（例如，在哪里放置每一张图片，用什么颜色渲染每一段文字）。这项工作是在一个单独的进程中完成的。一旦这个单独的进程弄清楚了所有的事情的位置，它就会把这些信息传递给Chrome主进程，后者会在屏幕上绘制所有的元素。
目前还不清楚你的视频sdk系统是如何设置的。但是你可以有一个进程来解压缩视频，另一个进程来渲染视频。然而，最有可能的是，你使用的是opengl或DirectX。这些API可能会对你如何在不同的进程之间划分内容施加一些限制。

我偶然发现了一篇文章，我觉得可以回答这个问题：https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/
基本上，底层技术是IPC和共享内存。有两种渲染模型：GPU加速和软件渲染。

GPU加速

客户端（在渲染器中或NaCl模块中运行的代码）不会直接向系统API发出调用，而是将其序列化，并将其放入驻留在自身和服务器进程共享的内存中的环形缓冲区（命令缓冲区）中。
服务器（GPU进程在限制较少的沙箱中运行，允许访问平台的3D API）从共享内存中获取序列化命令，解析它们并执行相应的图形调用。

软件渲染

这是一种旧的软件呈现模型，在这种模型中，呈现器进程（通过IPC和共享内存）将带有页面内容的位图传递给浏览器进程进行显示。

窗口对象--用于实现小部件的小的、可绘制的矩形区域，而不是用户看到的窗口, -可以使用共享内存或X协议在进程之间完美地共享。