Servo Engine Moves Painting to GPU to Erase Web Rendering Bottlenecks

Fastest browser engine by far at 500 FPS! Servo Webrender - CSS on the GPU part 2: Demo — 𝓖𝓷𝓸𝓶𝓮💫𝓢𝓪𝓷𝓮

𝓖𝓷𝓸𝓶𝓮💫𝓢𝓪𝓷𝓮

Because WebRender conducts full page repaints directly on the graphics card on every frame, painting ceases to bottleneck browsers and shifts performance constraints onto CPU-bound CSS restyling.

AI-assisted summary of Fastest browser engine by far at 500 FPS! Servo Webrender - CSS on the GPU part 2: Demo — original source. Check the original for full context.

Source published:

Key ideas

  • Servo's WebRender demonstrates standard web pages rendering in 0.46 ms (~500 FPS) and heavy CSS stress tests at over 300 FPS by executing full GPU repaints every frame, effectively eliminating painting as the primary browser bottleneck. (0:00)
  • Traditional web performance rules advising developers to avoid animating positioning properties or margins become obsolete in WebRender, as full repaints occur directly on the GPU without CPU repaint penalties. (3:04)
  • Clipping in WebRender avoids per-pixel alpha operations for rectangular bounds by computing intersected vertices and bilinear interpolation in vertex space, switching to fragment shader alpha masks only for rounded corners and complex shapes. (5:36)
  • WebRender's multi-threaded batching architecture was intentionally designed to accommodate Vulkan, enabling worker threads to record directly into hardware command queues and bypass dedicated GPU serialization threads. (11:12)
  • The Servo team's long-term roadmap focuses on pushing browser pipeline stages backwards into the GPU—including font rasterization, image decoding, and display list construction—to capitalize on GPU scaling while CPU single-core gains remain plateaued. (12:21)

Detailed notes

## Background Published on YouTube by 𝓖𝓷𝓸𝓶𝓮💫𝓢𝓪𝓷𝓮 on February 23, 2016, this video is an excerpt from the February 2016 Bay Area Rust Meetup demonstrating Servo's WebRender engine. The video description provides references to the original Mozilla Air stream along with links to nightly and alpha builds of the Servo browser project.

## TL;DR In this demonstration, the presenter showcases Servo's WebRender GPU pipeline running Wikipedia at roughly 500 frames per second and executing complex CSS stress benchmarks at over 300 frames per second. By performing full repaints directly on the GPU every frame, WebRender removes painting as the primary browser bottleneck, rendering traditional web performance tricks like avoiding positioning animations obsolete. During the audience Q&A, the speaker details how WebRender manages vertex and fragment shader clipping, coordinates with WebGL, and plans to leverage Vulkan to eliminate GPU thread serialization. The long-term vision focuses on pushing earlier pipeline phases—such as font rasterization and image decoding—directly onto the GPU to outpace plateauing single-core CPU performance.

## Atmosphere & style The presentation carries the relaxed, highly technical vibe of an intimate developer meetup, punctuated by casual remarks about projector lag and live shader reloading. There is an undercurrent of genuine excitement as the presenter nonchalantly runs stress tests that would freeze standard browsers, backing up the demonstrations with raw GPU millisecond timings. The Q&A transitions smoothly into an open architectural deep dive, leaving the audience with an inspiring, forward-looking glimpse into modern graphics plumbing and browser internals.

## Bulletin - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) Servo's WebRender demonstrates standard web pages rendering in 0.46 ms (~500 FPS) and heavy CSS stress tests at over 300 FPS by executing full GPU repaints every frame, effectively eliminating painting as the primary browser bottleneck. - [03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) Traditional web performance rules advising developers to avoid animating positioning properties or margins become obsolete in WebRender, as full repaints occur directly on the GPU without CPU repaint penalties. - [05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) Clipping in WebRender avoids per-pixel alpha operations for rectangular bounds by computing intersected vertices and bilinear interpolation in vertex space, switching to fragment shader alpha masks only for rounded corners and complex shapes. - [11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) WebRender's multi-threaded batching architecture was intentionally designed to accommodate Vulkan, enabling worker threads to record directly into hardware command queues and bypass dedicated GPU serialization threads. - [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) The Servo team's long-term roadmap focuses on pushing browser pipeline stages backwards into the GPU—including font rasterization, image decoding, and display list construction—to capitalize on GPU scaling while CPU single-core gains remain plateaued.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) Rendering Wikipedia in Servo with WebRender achieves roughly 500 FPS (0.46 ms GPU time), proving modern GPUs can effortlessly process standard web content at multiple hundreds of frames per second. - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) Artificial stress tests with hundreds of moving bordered elements run at 300+ FPS in WebRender, compared to approximately 1 FPS in traditional browser engines. - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) In visually complex scenes like rotating spheres with heavy CSS box shadows, WebRender shifts the primary bottleneck away from painting to CPU-bound CSS restyling and string parsing. - [03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) Established best practices restricting web animations to transform and opacity become obsolete under WebRender, as every frame undergoes a full GPU repaint. - [03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) Subtle rendering artifacts, such as unwanted lines across the screen, stem from pixel-snapping edge cases and unstandardized browser snapping behaviors. - [05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) Rectangular clipping is solved in vertex shaders using coordinate math and bilinear interpolation, reserving fragment shader alpha masks for rounded borders and non-rectangular paths. - [05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) External content like WebGL and HTML5 2D canvas is redirected into off-screen textures and composited directly into the master scene, mirroring operating system window managers. - [08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) Unlike legacy native UI toolkits retrofitted for hardware acceleration, WebRender is designed from the ground up around modern GPU pipelines, yielding superior rendering efficiency. - [08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) Emerging standards like the CSS Typed Object Model mitigate the need to pierce the CSS abstraction layer by eliminating CPU overhead from parsing coordinate strings. - [11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) WebRender separates batch building across worker threads, laying the architectural groundwork for direct command queue recording in Vulkan. - [11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) Adopting Vulkan is expected to reduce driver bugs substantially because its minimal driver footprint exposes far fewer error-prone edge cases than OpenGL stacks. - [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) The development philosophy behind WebRender seeks to push processing backwards from display output into the GPU until hitting an architectural barrier, targeting image decoding and font glyph rasterization next. - [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) Aggressively moving browser workloads to the GPU is motivated by hardware trends: CPU single-core performance has largely plateaued while GPU parallel throughput continues to advance rapidly.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) Live Demos: Wikipedia at 500 FPS and CSS Stress Benchmarks

The presenter opens the demonstration running Wikipedia inside Servo with the debug view enabled, relieved that recompilation was not required: “Thankfully I don't have to recompile.” Despite a small amount of visual lag introduced by the room's display projector, the page renders with extreme smoothness. The debug view reports a GPU time of merely 0.46 milliseconds per frame, which equates to roughly 500 frames per second. The presenter underscores the raw rendering capability of modern graphics hardware, declaring: “GPUs are very, very, very fast, and in fact, if you program them correctly, there is essentially no web page out there that they cannot get through in multiple hundreds of frames per second.” The built-in debugger also features live shader reloading, which allows developers to isolate and diagnose performance bottlenecks in real time. Because WebRender renders standard web pages so rapidly, finding any existing real-world page that slows it down proves difficult, prompting the team to construct artificial stress tests.

To demonstrate how the engine handles extreme stress, the presenter runs an artificial benchmark featuring several hundred moving `<div>` elements with visible borders over a continuously changing background. Standard web browsers struggle heavily with this kind of dynamic workload; running it in Firefox or competing browsers yields roughly one frame per second and risks freezing the application entirely. In WebRender, because all blitting and compositing are offloaded to and cached on the GPU, the entire benchmark executes effortlessly at roughly 1.1 to 1.2 milliseconds on the GPU, translating to at least 300 frames per second.

```mermaid flowchart TD accTitle: WebRender Bottleneck Elimination accDescr: Diagram contrasting traditional browser rendering bottlenecks with WebRender GPU acceleration. subgraph Traditional["Traditional Rendering Engine"] T1["DOM & CSS Restyling"] --> T2["Layout Calculation"] T2 --> T3["CPU Painting / Rasterization (Severe Bottleneck)"] T3 --> T4["Compositor"] end subgraph WR["Servo + WebRender"] W1["CSS Restyling / String Parsing (Current Bottleneck)"] --> W2["Layout"] W2 --> W3["WebRender GPU Pipeline (0.46–1.2 ms / 300–500 FPS)"] end ```

A second, more challenging benchmark showcases a collection of rotating 3D-like spheres constructed purely from CSS `<div>` elements styled with heavy box shadows. The presenter turns off the on-screen stats to showcase the effect, noting an inadvertent single-pixel white line cutting across the screen due to a rendering bug. Even with complex box shadows, the scene runs at a consistent 60 frames per second, a frame rate unattainable in traditional browsers. The presenter reveals that painting is not what limits performance here: the engine is bottlenecked by the CPU cost of calculating CSS restyling and applying absolute positioning properties every frame. The presenter sums up the achievement: “Essentially we've removed painting from the bottleneck in Servo.”

- Wikipedia debug rendering: 0.46 ms GPU time (~500 FPS). - Moving bordered `<div>` stress test: ~1.1 to 1.2 ms GPU time (~300+ FPS), compared to ~1 FPS in traditional engines. - Rotating spheres benchmark: Sustains 60 FPS using purely CSS `<div>` tags and box shadows. - Primary bottleneck shifted away from painting and onto CSS restyling and positioning updates.

---

[03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) Pixel Snapping Artifacts and Web Performance Best Practices

During the audience Q&A, an attendee asks about the visual artifact visible in the sphere demo—the unexpected white line running across the middle of the display. The presenter explains that it stems from either a shader calculation issue or subtle edge cases in their pixel snapping implementation. WebRender is actively working through bugs in pixel snapping, a notorious corner of web layout where CSS snapping rules are loosely specified or entirely unstandardized, requiring developers to reverse-engineer other browser rendering engines. High-DPI screens can introduce further rounding anomalies if screen metrics are misdetected. While subpixel positioning would mitigate some low-resolution display quirks, it has not yet been implemented in the engine.

Another audience member asks whether existing optimization tricks used by modern web developers might backfire or create technical debt once architectures like WebRender become standard. The presenter reassures the audience that conventional optimizations will not cause issues, though they make certain established rules of thumb obsolete. In particular, common web advice strongly urges developers to animate only `transform` and `opacity` while strictly avoiding animating `margin` or absolute positioning coordinates, as the latter trigger expensive CPU repaints. With WebRender, that constraint no longer applies:

> “Well, that advice is kind of obsolete with WebRender because everything is done in the GPU; we do full repaints on every frame.”

The presenter explains that because WebRender executes full repaints on every single frame directly on the GPU without differentiating between GPU-friendly and CPU-bound layout properties, animating absolute positioning is entirely viable and runs at roughly the same speed as transforms. Following older practices will not harm performance in WebRender; it simply represents unnecessary developer friction to work around limitations that no longer exist.

---

[05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) Clipping Techniques, Fragment Shaders, and WebGL Compositing

A question is raised regarding the mechanics of fast clipping in WebRender, specifically asking whether vertex shaders use alpha blending or another technique to clip elements. The presenter clarifies that for standard rectangular clipping—where one axis-aligned bounding box clips another—the engine does not need per-pixel alpha operations. Instead, it computes the newly intersected rectangular vertices directly in vertex space, applying bilinear interpolation to texture and color coordinates to calculate the adjusted geometry. For non-rectangular bounds such as rounded corners (`border-radius`), WebRender switches mechanisms, computing an alpha mask and evaluating it inside the fragment shader. The primary fragment shader is designed around a color texture, a mask texture, and a base color, which together resolve the vast majority of clipping operations, leaving only rare corner cases like nested `overflow: hidden` elements with arbitrary 3D transforms as complex exceptions.

```mermaid flowchart LR accTitle: WebRender Clipping Strategy accDescr: Pipeline choosing between vertex-level math and fragment-shader alpha masks. Clip{"Clipping Type"} Clip -->|"Rectangular Box"| Vtx["Vertex Shader Clipping"] Clip -->|"Rounded Rect / Complex"| Frag["Fragment Shader + Alpha Mask"] Vtx --> Out["Direct Bilinear Interpolation"] Frag --> Out ```

When asked how WebRender coordinates with WebGL content embedded on a page, the presenter explains that WebRender functions much like an operating system's compositing window manager:

> “So we're using OpenGL, they're using OpenGL; what we do is that that gets redirected to a texture, and we render that texture as part of the scene as just kind of an opaque thing that we render as part of the scene.”

Although WebGL is supported, its current implementation has room for optimization because rapid switching across multiple OpenGL contexts requires platform-specific graphics plumbing that has not yet been fully built out. The presenter anticipates that the HTML5 2D `<canvas>` API will follow an identical pattern, likely rendering via Skia GL into an off-screen texture before WebRender composites it directly into the master scene.

---

[08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) Comparisons to Native UI Toolkits and Exposing Raw Primitives

An audience member asks how WebRender compares to native UI toolkits such as Qt Quick. The presenter notes unfamiliarity with Qt Quick's internal pipeline, but contrasts WebRender against traditional native UI libraries. Most standard operating system UI toolkits were architected before GPU compositing became ubiquitous; as a consequence, they rely on vector graphics APIs originally created for CPU drawing and later adapted for hardware acceleration. Because WebRender was built from the ground up specifically around GPU execution models, it is fundamentally designed to make better use of GPU hardware than traditional toolkits, though newer mobile frameworks like iOS have advanced significantly compared to desktop predecessors like Cocoa. The presenter predicts WebRender should perform as well as, or even faster than, traditional native UI rendering frameworks.

Another attendee asks whether the Servo team has considered exposing WebRender's internal low-level graphics primitives directly to web developers so they can bypass CSS entirely. The presenter admits they have not explored exposing raw primitives, expressing hope that piercing the abstraction layer of CSS will never be necessary:

> “There's work in standards committees—Google has done great work on pushing things like Typed OM; hopefully with that kind of thing there won't need to be a sort of thing that pierces the veil of CSS because CSS will be such a tiny layer it won't matter anymore.”

In the sphere demo, the true performance limiter was not the complexity of the CSS styles, but the repeated CPU overhead of serializing and re-parsing style coordinate strings every time an element moved. Emerging specifications like the CSS Typed Object Model (Typed OM) allow values to be passed as structured typed data instead of strings, eliminating parser overhead. By streamlining CSS parsing and adopting improved standards, CSS can remain a lightweight, accessible layer that retains its ease of use without compromising near-metal rendering speeds.

[11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) Vulkan Support and Driver Architecture in WebRender

Answering an audience question regarding whether the team has evaluated Vulkan, the speaker reveals that Vulkan was actively considered from the project's inception. In fact, accommodating Vulkan was a primary reason behind WebRender's multi-threaded design. Under the existing OpenGL-based model, multiple worker threads build batches concurrently, but they must serialize their results and dispatch everything across to a single, dedicated GPU thread.

In a future Vulkan implementation, this bottleneck disappears: the worker threads and individual node compilers will be able to record and submit draw commands straight into Vulkan command queues without routing through a separate intermediary GPU thread. This eliminates cross-thread synchronization overhead. Beyond performance gains, the speaker notes that the graphics driver ecosystem would benefit dramatically, observing that Vulkan's considerably smaller API surface area translates to far fewer driver bugs in practice. As the speaker explains:

> “So the plan tentatively is we have all these worker threads that are building batches right now they have to serialize and push everything over to the GPU thread in the Vulkan world ideally um they would be able to directly insert into command queues and we wouldn't need that separate thread all of the node compilers just insert into the command queue directly which would eliminate uh some synchronization overhead so yeah I'm pretty excited about what Vulkan can bring also less buggy drivers would be wonderful um and Vulkan promises less buggy drivers because they're much smaller.”

```mermaid flowchart TD accTitle: Current WebRender vs Vulkan Execution Flow accDescr: Diagram contrasting WebRender's current batch serialization via a GPU thread against the proposed direct command queue submission in Vulkan.

subgraph Current ["Current Architecture (OpenGL)"] W1["Worker Thread 1"] -->|"Serialize & push"| GT["Dedicated GPU Thread"] W2["Worker Thread 2"] -->|"Serialize & push"| GT GT -->|"Execute calls"| GL["OpenGL Driver"] end

subgraph VulkanTarget ["Target Architecture (Vulkan)"] VW1["Node Compiler / Worker 1"] -->|"Record commands directly"| CQ["Vulkan Command Queues"] VW2["Node Compiler / Worker 2"] -->|"Record commands directly"| CQ CQ -->|"Submit queue"| VK["Vulkan Driver (Slim)"] end ```

- **Multi-threaded alignment**: WebRender's batching pipeline was purposefully decoupled across worker threads so that command generation could map cleanly to modern low-overhead APIs like Vulkan. - **Eliminating the dedicated GPU thread**: Direct-to-queue recording removes the serialization layer and synchronization stalls required by legacy graphics APIs. - **Driver reliability**: Vulkan drivers are dramatically thinner and less complex than traditional OpenGL driver stacks, substantially reducing client-side driver bug surface area.

[12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) Pushing the Rendering Pipeline Backwards into the GPU

Addressing whether WebRender aims to migrate even more browser responsibilities onto the GPU, the speaker responds enthusiastically in the affirmative. Work is already underway on offloading image codecs, font glyph rasterization, and potentially parts of display list construction onto hardware execution. The overarching architectural philosophy is to work backwards from the display output towards layout and parsing until a hard barrier is encountered. As the speaker puts it:

> “Basically my view is we should take the pipeline starting from the end the the end you know the end meaning the screen push that into the GPU and keep pushing backwards in the pipeline until we hit a wall and I and and I hope we don't hit that wall pretty soon.”

The ultimate vision is to achieve balanced, maximum utilization across both hardware processors: driving GPU execution to its maximum throughput while concurrently saturating the multi-core CPU. The speaker argues that shifting compute to graphics hardware will only grow in importance, pointing out that modern CPU single-core performance has largely plateaued while GPUs continue their aggressive upward trajectory in raw parallel processing power. Concluding the talk, the speaker opens the floor to informal one-on-one questions from the Bay Area Rust meetup attendees.

- **Candidate workloads for GPU offload**: Hardware image decoding and decompression codecs, runtime font glyph rasterization, and initial display list construction. - **Optimization target**: Symmetrical hardware saturation where both the CPU and GPU operate at peak capacity without either idling on the other. - **Hardware trends**: Offloading browser operations to the GPU is driven by hardware realities: CPU performance gains have largely stalled, whereas GPU parallel computing power continues to accelerate rapidly.

## Notable quotes > [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) GPUs are very, very, very fast, and in fact, if you program them correctly, there is essentially no web page out there that they cannot get through in multiple hundreds of frames per second.

## Mentioned Servo, WebRender, Wikipedia, Firefox, CSS, Typed OM, Google, WebGL, OpenGL, Vulkan, Skia GL, Qt Quick, iOS, Cocoa, Bay Area Rust meetup, Mozilla

## Video description Excerpted from https://air.mozilla.org/bay-area-rust-meetup-february-2016/ Servo can be found at https://servo-builds.s3.amazonaws.com/index.html and the latest Windows alpha build is at https://download.servo.org/nightly/windows/servo-latest.msi

[Source](https://www.youtube.com/watch?v=erfnCaeLxSI)

中文简报

Servo引擎将绘制工作移至GPU以消除Web渲染瓶颈 由于WebRender在每帧都直接在显卡上执行整页重绘，绘制不再是浏览器的瓶颈，性能限制转而落在受CPU限制的CSS样式重算上。 在本次演示中，演讲者展示了Servo的WebRender GPU流水线以约500 FPS的帧率运行维基百科，并以超过300 FPS的速度执行复杂的CSS压力基准测试。通过在每帧直接于GPU上进行全量重绘，WebRender消除了作为主要浏览器瓶颈的绘制过程，使避免定位动画等传统网页性能优化手段不再必要。在观众问答环节中，演讲者详细阐述了WebRender如何处理顶点与片元着色器裁剪、如何与WebGL协调，并计划利用Vulkan消除GPU线程串行化。长远构想侧重于将更早期的流水线阶段（如字体光栅化和图像解码）直接转移到GPU上，以应对CPU单核性能停滞不前的现状。 Servo的WebRender展示了标准网页以0.46毫秒（约500 FPS）渲染，并在繁重的CSS压力测试中超过300 FPS，这得益于每帧执行全量GPU重绘，从而切实消除了作为浏览器主要瓶颈的绘制问题。 (0:00) 建议开发者避免对定位属性或外边距进行动画处理的传统网页性能规则在WebRender中已不再适用，因为全量重绘直接在GPU上发生，无需承担CPU重绘代价。 (3:04) WebRender中的裁剪通过在顶点空间计算相交顶点和双线性插值，避免了矩形边界的逐像素Alpha操作，仅在面对圆角和复杂形状时才切换到片元着色器Alpha遮罩。 (5:36) WebRender的多线程批处理架构专为适配Vulkan而设计，使工作线程能够直接记录到硬件命令队列中，从而绕过专用的GPU串行化线程。 (11:12) Servo团队的长期路线图侧重于将浏览器流水线的前期阶段推向GPU（包括字体光栅化、图像解码和显示列表构建），以便在CPU单核性能增长停滞的情况下充分利用GPU的扩展优势。 (12:21)

Detailed notes — zh

## Background 该视频由 YouTube 频道 𝓖𝓷𝓸𝓶𝓮💫𝓢𝓪𝓷𝓮 于 2016 年 2 月 23 日发布。视频内容节选自 2016 年 2 月的湾区 Rust 线下聚会（Bay Area Rust Meetup），主要展示了基于 Rust 的 Servo 浏览器引擎及其 GPU 驱动渲染后端 WebRender 的现场演示与问答，简介中还提供了 Servo 的构建版本下载链接。 ## TL;DR 演讲者通过现场实机演示展示了 Servo 和 WebRender 的极限性能，维基百科页面渲染耗时仅 0.46 毫秒（接近 500 FPS），而足以让传统浏览器卡死的复杂 CSS 基准测试也能维持数百帧流畅运行。问答环节深入解析了矩形裁剪、Alpha 遮罩、WebGL 集成等底层机制，并指出由于 GPU 实现了每帧全量重绘，许多传统 CSS 优化经验已经过时。演讲者还探讨了原生 UI 架构对比与未来的 Vulkan 多线程命令提交支持，并提出了从屏幕端向流水线上游不断倒逼、将图像解码和字形光栅化等更多任务转移至 GPU 的激进演进策略。 ## Atmosphere & style 现场弥漫着硬核黑客聚会特有的极客热情与轻松自由的技术交流氛围。演讲者在展示恐怖性能数据时带着掩饰不住的自信与松弛感，演示中偶然冒出的小 Bug 更是引发了心照不宣的技术探讨。观众的提问直切底层图形管线要害，演讲者的回答既兼顾对传统标准（如 CSS Typed OM）的敬畏，又充满从屏幕端逆向压榨 GPU 极限算力的激进前瞻视野，整场互动既严谨扎实又极具启发性。 ## Bulletin - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) Servo 的 WebRender 架构在维基百科页面上实现单帧 0.46 毫秒的 GPU 渲染耗时（约 500 FPS），极限动态 CSS 测试可维持 300 FPS 以上，彻底移除了传统浏览器的绘制瓶颈。 - [03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) WebRender 每帧均在 GPU 上执行全量重绘，使传统前端“避免对 margin/定位属性做动画以防重绘”的性能优化法则彻底过时。 - [08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) 团队主张保留 CSS 声明式抽象，通过推动 Typed OM 等标准消除字符串解析开销，而非直接向开发者暴露命令式底层渲染图元。 - [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) 由于 CPU 算力增长放缓而 GPU 性能持续攀升，WebRender 确立了“从屏幕端反向推进”的架构路线，计划将图像解码、字形光栅化等更多流水线阶段移交 GPU。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) Servo 结合 WebRender 在维基百科页面实现了 0.46 毫秒的单帧渲染速度，帧率可达约 500 FPS。 - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) 极端 CSS 基准测试在传统浏览器中会降至 1 FPS 甚至卡死，但在 WebRender 中依靠全 GPU 混合与缓存可维持 300 FPS 以上。 - [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) CSS 旋转球体测试的瓶颈已不再是底层绘制，而是 JavaScript 更新绝对定位坐标时引发的 CSS 重算与样式解析。 - [03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) 由于每帧都在 GPU 上做全量绘制，关于仅对 transform 和 opacity 做动画的传统 Web 性能优化建议在 WebRender 中已变为无用功。 - [05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) 对于标准的矩形裁剪，WebRender 仅需在顶点着色器中计算新边界与双线性插值，无需进行昂贵的片元级逐像素计算。 - [05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) 圆角矩形和复杂边界通过片元着色器生成 Alpha 遮罩完成裁剪，同时 WebGL 和 Canvas 内容以共享纹理形式直接参与管线合成。 - [08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) 传统原生 UI 框架普遍依赖原本针对 CPU 设计的矢量 API，而在架构上纯 GPU 驱动的 WebRender 有潜力达到甚至超越原生 UI 的性能。 - [08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) 动画性能的主要杀手之一是频繁修改内联样式导致的 CSSOM 字符串解析，Typed OM 规范有望彻底解决此开销并保留 CSS 抽象。 - [11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) WebRender 最初就针对 Vulkan 的多线程模型设计，未来有望直接利用多命令队列消除独立的 GPU 提交线程与跨线程同步开销。 - [11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) Vulkan 驱动体积更小、Bug 更少，有助于改善当前 OpenGL 环境下长期困扰开发者的显卡驱动稳定性问题。 - [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) 鉴于 CPU 性能提升陷入停滞而 GPU 算力持续增长，团队确立了从屏幕端向流水线上游不断反推移交 GPU 的系统工程策略。 - [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) 未来 WebRender 计划探索将图像解码、字体字形光栅化以及显示列表构建等上游工作逐步迁移至 GPU 处理。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) 现场演示：维基百科与极端 CSS 基准测试 演讲者松了一口气，庆幸自己不需要现场重新编译代码。随后，他在投影仪上展示了维基百科在 Servo 调试视图（Debug View）下的渲染效果。尽管投影仪带来了一丝输入延迟，但整个页面滚动依然极其流畅迅速。调试数据直接显示，GPU 渲染耗时仅为 0.46 毫秒，换算下来相当于惊人的 500 FPS 左右。演讲者强调，只要正确编程，GPU 的性能极其恐怖：“so GPUs are very very very fast and in fact if you program them correctly there is essentially no web page out there that they cannot get through in multiple hundreds of frames per second.” 系统内置的调试器还具备实时重载着色器（Live Shader Reload）等功能，极大地方便了性能瓶颈的快速排查。因为 WebRender 在现有的普通网页上表现过于极致，甚至很难找到能让它变慢的真实网站，于是团队构建了一些极限压力基准测试。首先展示的是一个包含数百个带边框 `<div>` 的纯 CSS 动态页面，元素在屏幕上不断移动且背景疯狂变换。演讲者坦言他绝不敢在 Firefox 或其他浏览器里打开这个页面，因为那些浏览器会直接掉到 1 FPS 甚至彻底卡死；而在 WebRender 中，所有图形混合（blending）和缓存全部直接交由 GPU 完成，页面运行在 300 FPS 以上（耗时仅约 1.1 到 1.2 毫秒）。 接下来是一个压力更大的旋转球体演示。页面中的所有小球其实都是利用 CSS `box-shadow` 特性绘制的 `<div>` 元素。虽然屏幕中央因为着色器或像素对齐的一个小 Bug 出现了一条多余的白线，但整个场景仍然稳定在 60 FPS 运行——在其他主流浏览器中完全不可能达到这个帧率。演讲者指出，此时的系统瓶颈已经不再是渲染本身，而是为了给绝对定位的元素更新坐标所产生的 CSS 重算（Restyling）。将全部绘制移交 GPU 后，Servo 已经彻底消除了传统浏览器的绘制（Painting）瓶颈。 - 维基百科在 Servo 调试视图下的 GPU 单帧渲染时间为 0.46 毫秒，帧率约为 500 FPS。 - 调试工具支持实时着色器重载（Live Shader Reload），便于定位调试。 - 动态边框 `<div>` 极限测试在普通浏览器中会卡死至 1 FPS，而在 WebRender 中可维持 300 FPS 以上（单帧耗时 1.1~1.2 毫秒）。 - CSS `box-shadow` 旋转球体测试受限于 CSS 重算而非图形绘制，但依然能跑满 60 FPS。 --- ### [03:04](https://www.youtube.com/watch?v=erfnCaeLxSI&t=184s) 问答环节：像素对齐与现代 Web 优化技巧的反思 现场观众就旋转球体中间出现的白色细线提问。演讲者解释这可能是当前着色器的问题，或者更可能是像素对齐（Pixel Snapping）逻辑的 Bug。CSS 的像素对齐规则非常微妙且常常缺乏官方标准规范，引擎开发者往往不得不去逆向工程其他浏览器的行为。此外，高 DPI（HiDPI）检测与缩放处理也可能诱发这类单像素瑕疵，在当前没有亚像素定位（Subpixel Positioning）的情况下，这种低分辨率显示器上的小误差就暴露出来了。 随后有观众提问：现代前端开发者为了在传统浏览器上压榨性能而总结出的优化手段，在面对 WebRender 这类新架构时，是否会过时甚至适得其反？演讲者明确表示这些旧技巧不会造成性能损害，但很多已经彻底变成了“无用功”。最典型的例子就是大家普遍信奉的黄金法则：“只对 `transform` 和 `opacity` 做动画，千万别对 `margin` 或绝对定位属性做动画，因为后者会触发重绘（repaint）且无法利用 GPU。”演讲者直接打破了这一传统共识：“Well, that advice is kind of obsolete with WebRender because everything is done in the GPU. We do full repaints on every frame; we don't really have this distinction between things that that can be done on the GPU and things that can't.” 在 WebRender 看来，由于每帧都会在 GPU 上做全量绘制，绝对定位与变换属性的性能开销几乎没有区别。旧的开发模式虽然徒增了开发者的心智负担，但并不会让页面在 WebRender 中变慢。 --- ### [05:36](https://www.youtube.com/watch?v=erfnCaeLxSI&t=336s) 顶点裁剪、Alpha 遮罩与 WebGL 集成 一名观众深入探讨了渲染底层的实现方式，询问顶点着色器（Vertex Shader）在执行快速裁剪时是否使用了 Alpha 混合（Alpha Blending）。演讲者解释称，对于常规的矩形到矩形裁剪，根本不需要在片元阶段进行任何逐像素运算；程序只需直接计算出裁剪后矩形的新顶点坐标，再对纹理坐标和颜色坐标进行双线性插值（Bilinear Interpolation）即可。只有当遇到圆角矩形（Rounded Rectangles/Borders）等复杂几何形状时，系统才会在片元着色器（Fragment Shader）中计算 Alpha 遮罩（Alpha Mask）。主片元着色器依靠颜色纹理、遮罩纹理以及基础颜色这几项输入，就能覆盖绝大部分复杂的 CSS 裁剪需求。 关于 WebRender 与 WebGL 及 Canvas 的集成机制，演讲者解释其逻辑类似于合成窗口管理器（Compositing Window Manager）。由于两者底层都依赖 OpenGL，WebGL 的输出会被直接重定向渲染到一个纹理中，然后 WebRender 将这个纹理作为场景中的一个不透明矩形直接合并绘制。目前 Servo 已经支持 WebGL，虽然尚未加入特定操作系统的深层优化，但在架构原理上完全能够实现极高速度。对于传统的 2D Canvas，未来的计划也是通过 Skia-GL 等硬件加速库先渲染为纹理，再直接合成进 WebRender 的绘制流水线中。 ```mermaid flowchart TD accTitle: WebRender 裁剪与合成流水线架构 accDescr: 展示 WebRender 如何分别处理矩形裁剪、圆角遮罩以及将 WebGL 纹理整合输出。 subgraph Geometry["几何计算阶段"] A["矩形对矩形裁剪"] -->|"计算新边界与双线性插值"| B["顶点着色器处理"] C["圆角矩形/特殊边框"] -->|"生成 Alpha Mask"| D["片元着色器处理"] end subgraph Integration["外部图形输入"] E["WebGL 内容"] -->|"重定向"| F["共享 GL 纹理"] G["Canvas (Skia-GL)"] -->|"光栅化"| F end subgraph Composition["最终着色与合成"] B --> H["主合成着色器"] D --> H F -->|"视为不透明纹理直接合成"| H H --> I["GPU 最终帧输出"] end ``` --- ### [08:14](https://www.youtube.com/watch?v=erfnCaeLxSI&t=494s) 原生 UI 对比与底层绘图 API 的未来 针对 WebRender 与 Qt Quick 或原生 UI 工具包（如 Cocoa、iOS UI）的性能对比，演讲者表示自己虽然不熟悉 Qt Quick，但传统原生 UI 框架的架构多半是在 GPU 合成普及之前设计的。这些框架通常建立在最初为 CPU 设计、后来才移植到 GPU 的矢量图形 API 上，因此在 GPU 的高效利用率上天生落后于从零为 GPU 打造的 WebRender。演讲者指出，虽然不同平台差异很大（例如 iOS 对 GPU 的支持显著优于 Mac 上的 Cocoa），但从架构理念而言，WebRender 的极限绘制表现应当“达到甚至超越原生”（as fast as native, or faster than native）。 最后，有观众提出一个激进的设想：既然 WebRender 的底层只有少数几个极度高效的图元（Primitives），为什么不直接向开发者暴露这些底层 API 来写界面，从而彻底绕开繁重的 CSS 体系？演讲者对这个想法表示理解，但他更希望保留 CSS 的易用性，而不是“刺穿 CSS 的面纱”。他强调，旋转球体演示中的瓶颈其实是 JavaScript 频繁修改内联样式时，引擎不得不反复对字符串形式的数字进行解析。解决之道并非废弃 CSS，而是通过规范演进消除多余的抽象层。演讲者特别提到了 Google 在推行 Typed OM（类型化 CSS 对象模型）方面所做的出色工作，并明确表态：“My hope is that in the future we will actually be able to... web authors will actually not need to have a separate thing; they'll just write, you know, some sort of CSS and it'll just work.” 他希望通过改进底层标准，让 CSS 变成一层薄到不再产生开销的优秀声明式接口，让开发者能继续享受其便利。 - 传统原生 UI 框架底层普遍受制于遗留的矢量图形 API，对现代 GPU 的调配往往不及纯 GPU 驱动的 WebRender。 - 动态属性频繁修改的真正性能杀手往往是 CSSOM 字符串解析开销。 - 演讲者提倡通过推动 Typed OM 等现代 Web 标准来消除中间损耗，主张保留 CSS 声明式语法的易用性，而非退回到命令式底层 API。 ### [11:12](https://www.youtube.com/watch?v=erfnCaeLxSI&t=672s) Vulkan 支持与多线程命令提交的前景 现场观众提问团队是否考虑过引入新一代图形 API Vulkan。演讲者对此做出了非常积极的回应，表示团队从项目设计伊始就一直将 Vulkan 铭记在心。事实上，WebRender 之所以从一开始就采用多线程架构，很大程度上正是为了适应 Vulkan 的运作机制。 在现有的架构实现中，多个工作线程（worker threads）负责并行构建批次（batches），但由于传统图形 API 的约束，它们最终必须将数据序列化并统一推送到一个单独的 GPU 线程中执行。演讲者畅想道，在理想的 Vulkan 环境下，所有的节点编译线程可以直接向各个命令队列（command queues）写入渲染指令，彻底省掉中间这个独立的 GPU 调度线程。这不仅能直接消除线程间的同步开销（synchronization overhead），还能大幅提升执行效率。除此之外，演讲者对驱动层面的改善同样充满期待，他指出 Vulkan 的驱动体积要小得多，因而能够有效解决长期困扰开发者的显卡驱动 Bug 频发的问题。 ```mermaid flowchart TD accTitle: 当前 OpenGL 与未来 Vulkan 命令提交流程对比 accDescr: 展示了当前依赖单一 GPU 线程进行序列化提交与未来 Vulkan 支持多线程直接写入命令队列的架构演进 subgraph Current ["当前架构 (OpenGL)"] W1["工作线程 1"] --> S["序列化与跨线程同步"] W2["工作线程 2"] --> S S --> GT["独立 GPU 线程"] GT --> Driver["庞大且易出 Bug 的驱动"] end subgraph VulkanFuture ["未来规划 (Vulkan)"] VW1["节点编译线程 1"] --> Q1["命令队列 A"] VW2["节点编译线程 2"] --> Q2["命令队列 B"] Q1 --> VDriver["轻量可靠的 Vulkan 驱动"] Q2 --> VDriver end ``` - 演讲者对驱动改善抱有强烈期望，他直言：“also less Buggy Drive would be wonderful um and Vulcan promises less buggy drivers because they're much smaller” - 当前瓶颈在于多线程生成的渲染批次必须向单一 GPU 线程归拢，而 Vulkan 原生支持多线程并行录制指令列表，能够真正释放并发性能。 ### [12:21](https://www.youtube.com/watch?v=erfnCaeLxSI&t=741s) 从屏幕端反向推进：将更多渲染流水线移交 GPU 针对观众关于“是否考虑将更多工作卸载（offload）到 GPU”的提问，演讲者给出了极为坚决的肯定答复。他透露自己正在针对图像解码器（image codecs）展开研究，并计划在后续演讲中分享成果。此外，团队还在积极探索字体字形光栅化（font glyph rasterization）以及显示列表构建（display list construction）等环节在 GPU 上的实现途径。 在阐述技术愿景时，演讲者提出了一个非常激进且清晰的系统工程策略：从渲染流水线的终点（即屏幕呈现端）开始切入，将其全部推给 GPU，然后沿着流水线不断向源头“倒逼推进”，直到碰壁为止。演讲者强调，考虑到当前 CPU 算力增长已经放缓陷入停滞（stalled），而 GPU 性能仍在以惊人的速度持续暴涨，将更多负载迁移至 GPU 在未来将变得愈发关键。团队的长远目标绝非止步于现有的性能突破，而是要实现 GPU 算力与 CPU 算力的双向完全榨干与充分利用，从而使整个渲染引擎达到理论上的最优运行状态。在回答完此问题后，演讲者向现场观众致谢并宣布进入会后自由交流环节。 - 演讲者鲜明地总结了自己的架构哲学：“basically my view is we should take the pipeline starting from the end the the end you know the end me the screen push that into the GPU and keep pushing backwards in the pipeline until we hit a wall and I and and I hope we don't hit that wall pretty soon” - 演讲者对硬件发展趋势作出了敏锐判断：“it's going to be increasingly important to do that going forward given that gpus are just getting more and more and more powerful and CPUs have kind of stalled” - 潜在迁往 GPU 的上游任务包括：图像解码、文字字形光栅化以及部分显示列表结构的生成。 ## Notable quotes > [00:00](https://www.youtube.com/watch?v=erfnCaeLxSI&t=0s) so GPUs are very very very fast and in fact if you program them correctly there is essentially no web page out there that they cannot get through in multiple hundreds of frames per second. ## Mentioned Servo, WebRender, GPU, CSS, Wikipedia, Firefox, WebGL, Canvas, OpenGL, Skia-GL, Qt Quick, Cocoa, iOS, Google, Typed OM, Vulkan ## Video description Excerpted from https://air.mozilla.org/bay-area-rust-meetup-february-2016/ Servo can be found at https://servo-builds.s3.amazonaws.com/index.html and the latest Windows alpha build is at https://download.servo.org/nightly/windows/servo-latest.msi [Source](https://www.youtube.com/watch?v=erfnCaeLxSI)

Source quotes

[0:00] so GPUs are very very very fast and in fact if you program them correctly there is essentially no web page out there that they cannot get through in multiple hundreds of frames per second.

Source quotes

[0:00] GPUs are very, very, very fast, and in fact, if you program them correctly, there is essentially no web page out there that they cannot get through in multiple hundreds of frames per second.

Original transcript

[0:00] there okay uh thankfully I don't have to [0:02] recompile okay so here's [0:04] uh here's and there's a little lag [0:06] because of the the projector but um so [0:09] here's Wikipedia with the debug uh with [0:11] the Sero debug View and um you can see [0:14] that it's very uh very smooth and fast [0:16] and in fact it's rendering at um the GPU [0:22] time is 046 milliseconds um which is a [0:27] lot of frames per second I think it's [0:28] something like 500 um [0:31] so gpus are very very very fast and in [0:34] fact if you program them correctly there [0:36] is essentially no web page out there [0:37] that they cannot get through in multiple [0:39] hundreds of frames per second um so uh [0:43] this this also shows kind of a debugger [0:45] um we have uh we have a debugger that [0:49] allows has some pretty nice features [0:51] like life Shader reload um that gives us [0:55] it allows us to very quickly uh trck [0:56] down performance problems so because [1:00] we're really fast existing web page and [1:01] it's actually kind of hard to find a web [1:03] page that we're um slow on so we have [1:08] some uh we have a few benchmarks um and [1:12] these are totally artificial bench [1:14] benchmarks um but uh they basically kind [1:18] of push things to to the Limit and here [1:21] is one of the uh here is a pretty uh [1:25] Benchmark and this is actually um [1:28] entirely done in CSS [1:30] with divs that have uh borders so this [1:33] is a few hundred divs that have borders [1:35] that are moving around um and the [1:37] background is changing all the time uh [1:40] and I will not show this in Firefox or [1:43] other browsers because it's like one [1:45] frame per second and we'll freeze my [1:46] browser but it is uh but it it's very uh [1:51] fast here because we essentially did all [1:53] of the bleding on the GPU we cached it [1:55] all and in fact uh what is it it's like [1:58] 1.2 on the C [2:00] 1.1 so it's about 300 something frames [2:02] per second probably at least um and here [2:06] here's another demo um and this one is [2:08] much much slower here's a bunch of [2:10] rotating spheres that are actually uh [2:13] all CSS divs using uh box [2:16] Shadows I I can remove the uh the stats [2:20] so you can see it a little better um oh [2:22] there's a white line across the middle [2:23] oh well I was uh that's a bug we need to [2:26] fix but anyway um [2:30] aside from that one pixel it's it's [2:31] going at about 60 frames per second and [2:33] this is not 60 frames per second [2:34] elsewhere um and the uh and and what's [2:40] actually what we're actually bottleneck [2:41] here on is the CSS restyling setting the [2:44] new CSS properties uh necessary to [2:48] position all of these things absolutely [2:50] is quite a bit slower than painting all [2:52] of it um [2:54] so essentially [2:57] we've we've removed painting from the [2:59] bottleneck [3:00] in Servo so [3:04] uh so I have are there any uh [3:08] questions [3:12] sure yeah uh I'm not actually sure that [3:18] doesn't that may have been an issue with [3:20] our that may have either been an issue [3:21] with our shaer or with our pxel snapping [3:23] code that's one of the things we're uh [3:25] picking bugs out of right now um pixel [3:27] snapping is a whole area I didn't get [3:28] into but csss these tricky pixel [3:30] snapping rules that are actually kind of [3:32] not even spec and you kind of have to [3:34] reverse engineer other browsers um and [3:37] we're still picking bugs out of that in [3:39] web render um that may have been some of [3:41] it it also may have been uh High DPI [3:43] issues so they it may be that uh it's [3:47] detecting the high DPI wrong and pixel [3:49] snapping in in some weird way but that's [3:51] that's basically what that is uh we [3:53] don't have some pixel positioning yet at [3:54] the moment which doesn't matter on high [3:56] DPI but uh it can matter in lower [3:59] resolution like [4:01] this anything else uh sure are teches [4:05] that modern web developers are using to [4:09] speed up performance of their website is [4:11] that going to cause backlash per se as [4:15] this type of stuff becomes mature so I [4:17] guess are techniques that people are [4:18] doing now to make it faster or they want [4:20] to bite us later when we have these [4:22] optimizations that's a very good [4:23] question I don't so the question was uh [4:26] are there are the techniques that web uh [4:28] developers are using now are they going [4:30] to uh cause problems for this new sort [4:33] of uh rendering architecture and they [4:36] will not cause problems we can so in [4:38] particular there is one technique that [4:41] is uh very that is often heard as [4:43] performance advice that is very kind of [4:44] specialized to existing uh you know [4:47] normal painting backends which is [4:49] animate transforms and opacity um people [4:51] say don't animate margins don't animate [4:54] absolute positioning because that's slow [4:55] causes repaints um can't be done on the [4:58] GPU well [5:00] that advice is kind of obsolete with web [5:02] render because everything is done in the [5:04] GPU we do full repaints on every frame [5:06] we don't really have this distinction [5:07] between things that that can be done on [5:09] the GPU and things that can't um I don't [5:11] think it will hurt us it it shouldn't it [5:13] shouldn't hurt us I mean it's just it's [5:15] a slightly more annoying way to do the [5:17] same thing like now absolute positioning [5:19] is something that's viable as a it [5:21] should be about the same speed as [5:24] transforms uh so it's kind of needless [5:27] developer pain but uh it shouldn't hurt [5:29] us [5:30] in in terms of uh in terms of a [5:32] performance can be a [5:36] problem you said you're you're using the [5:39] vertex Shader to do to do the the fast [5:42] clipping um are are you is that using [5:46] Alpha blending or or or some some [5:50] other uh so okay so the question was do [5:53] we use Alpha blending to do the uh to do [5:56] the the clipping um and [6:00] if if I understand you right the [6:03] um so for the main clipping where you're [6:06] just clipping a rectangle to a rectangle [6:08] we don't actually need to do any per [6:11] pixel stuff at all all all we do is we [6:13] compute the new boundaries of the [6:14] rectangle and then we take you know [6:16] things like the vert the texture [6:17] coordinates the color coordinates and B [6:19] and do bilinear interpolation to figure [6:21] out the new ones so it's basically just [6:23] taking vertex to ver vertex clipping [6:25] there is a more complex one uh which is [6:27] rounded rectangles when you have like [6:29] round borders then we actually have to [6:31] do compute an alpha mask and do that in [6:33] the fragment Shader um but that is [6:37] that's that's not a problem it's just [6:38] it's a slightly different mechanism um [6:40] yeah I've done the alpha [6:43] mask yeah yeah so I mean basically our [6:45] main ver our main fragment Shader does [6:47] like has a color texture a mask texture [6:50] and color and a color and uh with that [6:54] you can pretty much do all the the [6:56] clipping that you need um in most cases [6:58] unless the only case that's really weird [7:00] is the one where you have like overflow [7:01] hidden div with a weird transform inside [7:04] um but that's pretty [7:12] rare uh so the question is how this [7:14] interacts with webg um and basically [7:18] it's the same thing that a compositing [7:19] window manager would do so we're using [7:22] openg they're using open G what we do is [7:25] that that gets redirected to a texture [7:26] and we render that texture as part of [7:28] the scene as just just kind of an opaque [7:30] thing that we render as part of the [7:31] scene um we we do have webgl support [7:34] right now um it's not it's not as fast [7:36] as it could be um because to make [7:39] context to make multiple GL context fast [7:41] you kind of have to do like OS specific [7:44] stuff that we haven't done yet um but [7:46] there's no reason in principle why it it [7:48] it can't be fast so it basically becomes [7:50] like a traditional compositor for the [7:52] case of webgl um and I think canvas will [7:55] likely be that way too canvas will [7:57] probably be rendered using ski AGL or [7:59] something like that and uh composited [8:01] into the web into the web [8:04] rendery any other [8:14] questions uh so the question is how does [8:15] it compare to cute quick or a native UI [8:17] toolkit so I don't really know how cute [8:19] quick Works um so I don't know um when [8:24] it comes to Native UI toolkits uh it [8:28] kind of depends on OS but in general [8:31] native UI toolkits are written uh [8:34] because they're they usually predate a [8:37] GPU compositing they're usually written [8:39] to um ex vector graphics apis like like [8:43] the ones I mentioned in the beginning [8:44] that are uh that were started as CPU and [8:47] then moved to the GPU so I don't think [8:48] they so web render is in principle um [8:51] something that makes better use of the [8:53] GPU however you know this this changes [8:56] quite a bit iOS is significantly better [8:58] for the GPU than than Coco is for [9:00] example um so these things these things [9:03] change quite a bit but overall uh I mean [9:07] web render's [9:09] pretty I I don't think you're going to [9:11] be doing much better than web render [9:12] it's it's pretty optimal but you know uh [9:15] the but it it really depends on the UI [9:17] tool kit in question I I think that it [9:19] should be as fast as native I mean or or [9:22] faster than native [9:30] API half a dozen Primitives that you [9:32] have and exposing that kind of at a user [9:35] level for WR to write do directly [9:37] instead of writing CSS uh so the [9:39] question is uh has there been any [9:42] thought about taking uh our Primitives [9:44] and exposing them directly instead of [9:45] through CSS and that's that's an [9:48] interesting idea I haven't really [9:51] thought too much about it we are [9:53] certainly I hope that that that we don't [9:56] have to do that because uh there's a lot [9:58] of stuff that's basically um removing [10:02] the layers of CSS that are needless [10:04] abstractions right now um so that my [10:07] hope is that in the future we will [10:08] actually be able to web web authors will [10:11] actually not need to have a separate [10:13] thing they'll just write you know some [10:15] sort of CSS and it'll just work you know [10:17] things like uh so right now actually the [10:19] bottleneck um for the the Spheres demo [10:22] was actually is actually parsing the [10:24] numbers that are in the CSS because you [10:27] know when you move the sphere you have [10:28] to uh set a string which think it's [10:30] parsed again a CSS that's kind of [10:32] needless overhead um there's work in [10:34] standard committee uh Google has done [10:35] great work on the uh pushing things like [10:37] type cssom um hopefully with that kind [10:40] of thing there won't need to be uh a [10:42] level of a sort of thing that pierces [10:45] the veil of CSS because CSS will be such [10:47] a tiny layer it won't matter anymore um [10:49] and to the extent that it's not a tiny [10:51] layer I think we should be working on [10:52] new standards and new specs that help it [10:55] become a such a small layer that it [10:56] doesn't matter matter anymore um I I I [10:59] hope that people will not I CSS is uh [11:04] pretty easy to use and I hope to [11:07] maintain its ease of use you you know uh [11:10] going forward while allowing people to [11:12] get the best performance that they [11:20] can yeah so the question is uh have we [11:23] looked into Vulcan and that's actually [11:25] great a great question we have had [11:27] Vulcan in the mind from in mind from the [11:28] beginning [11:29] that's part of the reason that's much of [11:31] the reason we had the multi-threaded [11:32] architecture um So the plan tentatively [11:35] is we have all these worker threads that [11:37] are building batches right now they have [11:39] to serialize and push everything over to [11:40] the GPU thread in the Vulcan World [11:43] ideally um they would be able to [11:45] directly insert into command cues and we [11:46] wouldn't need that separate thread all [11:48] of the node compilers just insert into [11:50] the command que directly which would [11:52] eliminate uh some synchronization [11:54] overhead so yeah I'm pretty excited [11:56] about what Vulcan can bring also less [11:58] Buggy Drive would be wonderful um and [12:01] Vulcan promises less buggy drivers [12:03] because they're much [12:04] smaller anything [12:21] else right yeah so the question is is [12:24] there more work that we thought about [12:25] moving to the GPU and the answer is [12:27] definitely yes I uh I hope to be talking [12:30] about some uh work I've so uh I've been [12:33] doing on image codex um so we're looking [12:35] at things like image codex we're looking [12:37] at font glyph rasterization I alluded to [12:39] that earlier um basically my view is we [12:43] should take the pipeline starting from [12:45] the end the the end you know the end me [12:48] the screen push that into the GPU and [12:51] keep pushing backwards in the pipeline [12:52] until we hit a wall and I and and I hope [12:55] we don't hit that wall pretty soon so [12:56] we're looking at things like glyph [12:57] rasterization and maybe um you know [13:00] getting some of the displays [13:01] construction to be on the GPU things [13:03] like that um So eventually hopefully [13:07] we'll hit full utilization of the GPU [13:10] capacity and full utilization of the CPU [13:11] capacity and then we'll be running [13:13] optimally but there's I definitely don't [13:15] want to stop here I think that there's [13:17] there's a lot more that we can continue [13:19] to do um with the GPU and it's going to [13:21] be increasingly important to do that [13:22] going forward given that gpus are just [13:25] getting more and more and more powerful [13:26] and CPUs have kind of stalled [13:30] anything else okay great well uh thank [13:33] you um and I'll be available for [13:34] questions afterward if anyone wants to [13:36] talk thanks