5 ms·

How does the rendering performance of this compare to something like Skia or Pathfinder? Note that the latter can also optionally do the paths-to-triangles conv

How does the rendering performance of this compare to something like Skia or Pathfinder? Note that the latter can also optionally do the paths-to-triangles conversion step using GPU compute, if the hardware supports that. There's also Vello for a more comprehensive compute-based approach to 2D rendering.

neurowave 3y ago
We need to do some newer benchmarking, the Rive Renderer has gotten faster since these initial tests: https://twitter.com/guidorosso/status/1595187838454140928 https://twitter.com/guidorosso/status/1595187838454140928
- emmanueloga_ 3y ago
  Can you talk a bit about text rendering? How does it compare to slug? [1] Would it be suitable for rendering text heavy applications? (like, say, a PDF viewer, a code editor, web browser, etc). -- 1: https://sluglibrary.com/ https://sluglibrary.com/
  - csmartdalton 3y ago
    The Rive renderer takes an animation-first approach to all path rendering, including text. Meaning, every glyph is redrawn from raw bezier curves with full precision antialiasing, every frame. (Just like any other path.) This optimizes the smoothness of animation, is fast enough to render fullscreen pages on top of pages of high dpi text at 120fps (on a decent GPU), and the antialiasing quality is always full precision in the (0..255) color channels. If you want more niche text-specific features like hinting and clear text, those aren’t supported because they don’t animate smoothly and/or don’t work as well with colors other than black and white. I recommend trying all the options for your specific needs and finding what works best!
    - qmathe 3y ago
      How is antialiasing implemented in the Rive renderer? It doesn't appear to be using MSAA. I took a look at the source code, I found some shaders that mention coverage and AA, but I cannot figure out how it works.
mtklein 3y ago
Looking at the GPU tech used and the committer names in that repo, I'm pretty confident this will at very least compete with both Skia and Pathfinder. I'm not super familiar with Vello. These are solid tech choices by people who know what they're doing... definitely worth the effort to check its performance and quality out for yourself. These GPU-first renderers all have slightly different approaches and each probably occupies a best-in-class niche for some multidimensional space of quality x performance x hardware/driver support x ease of integration. If you're not happy with one of the four, the others are all worth checking out.
- ignoramous 3y ago
  > I'm pretty confident this will at very least compete with both Skia and Pathfinder Couldn't Vello be embed / used by Skia, Cairo et al, if those renderers wanted to use GPU Compute instead of CPU's for preprocessing?
  - zozbot234 3y ago
    Skia does include some support for using Vello for rendering but it's just experimental, not enabled by default.
tehsauce 3y ago
At least one of their runtime implementations I checked out was implemented on top of Skia. Looks like they support a number of possible backends!
raphlinus 3y ago
I'm looking forward to doing careful benchmarking, as this renderer absolutely looks like it will be competitive. It turns out that is really hard to do, if you want meaningful results. My initial take is that performance will be pretty dependent on hardware, in particular support for pixel local storage[1]. From what I've seen so far, Apple Silicon is the sweet spot, as there is hardware support for binning and sorting to tiles, and then asking for fragment shader execution to be serialized within a tile works well. On other hardware, I expect the cost of serializing those invocations to be much higher. One reason we haven't done deep benchmarking on the Vello side is that our performance story is far from done. We know one current issue is the use of device atomics for aggregating bounding boxes. We have a prototype implementation [2] that uses monoids for segmented reduction, and that looks like a nice improvement. Additionally, we plan to do f16 math (which should be a major win especially on mobile), as well as using subgroups for various prefix sum steps (subgroups are in the process of landing in WebGPU[3]). Overall, I'm thrilled to see this released as open source, and that there's so much activity in fast GPU vector graphics rendering. I'd love to see a future in which CPU path rendering is seen as being behind the times, and this moves us closer to that future. [1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/dawn/features/pixel_local_storage.md https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da... [2]: https://github.com/linebender/vello/issues/259 https://github.com/linebender/vello/issues/259 [3]: https://github.com/gpuweb/gpuweb/issues/4306 https://github.com/gpuweb/gpuweb/issues/4306

neurowave 3y ago

We need to do some newer benchmarking, the Rive Renderer has gotten faster since these initial tests: https://twitter.com/guidorosso/status/1595187838454140928 https://twitter.com/guidorosso/status/1595187838454140928

emmanueloga_ 3y ago
Can you talk a bit about text rendering? How does it compare to slug? [1] Would it be suitable for rendering text heavy applications? (like, say, a PDF viewer, a code editor, web browser, etc). -- 1: https://sluglibrary.com/ https://sluglibrary.com/
- csmartdalton 3y ago
  The Rive renderer takes an animation-first approach to all path rendering, including text. Meaning, every glyph is redrawn from raw bezier curves with full precision antialiasing, every frame. (Just like any other path.) This optimizes the smoothness of animation, is fast enough to render fullscreen pages on top of pages of high dpi text at 120fps (on a decent GPU), and the antialiasing quality is always full precision in the (0..255) color channels. If you want more niche text-specific features like hinting and clear text, those aren’t supported because they don’t animate smoothly and/or don’t work as well with colors other than black and white. I recommend trying all the options for your specific needs and finding what works best!
  - qmathe 3y ago
    How is antialiasing implemented in the Rive renderer? It doesn't appear to be using MSAA. I took a look at the source code, I found some shaders that mention coverage and AA, but I cannot figure out how it works.

mtklein 3y ago

Looking at the GPU tech used and the committer names in that repo, I'm pretty confident this will at very least compete with both Skia and Pathfinder. I'm not super familiar with Vello. These are solid tech choices by people who know what they're doing... definitely worth the effort to check its performance and quality out for yourself. These GPU-first renderers all have slightly different approaches and each probably occupies a best-in-class niche for some multidimensional space of quality x performance x hardware/driver support x ease of integration. If you're not happy with one of the four, the others are all worth checking out.

ignoramous 3y ago
> I'm pretty confident this will at very least compete with both Skia and Pathfinder Couldn't Vello be embed / used by Skia, Cairo et al, if those renderers wanted to use GPU Compute instead of CPU's for preprocessing?
- zozbot234 3y ago
  Skia does include some support for using Vello for rendering but it's just experimental, not enabled by default.

tehsauce 3y ago

At least one of their runtime implementations I checked out was implemented on top of Skia. Looks like they support a number of possible backends!

raphlinus 3y ago

I'm looking forward to doing careful benchmarking, as this renderer absolutely looks like it will be competitive. It turns out that is really hard to do, if you want meaningful results. My initial take is that performance will be pretty dependent on hardware, in particular support for pixel local storage[1]. From what I've seen so far, Apple Silicon is the sweet spot, as there is hardware support for binning and sorting to tiles, and then asking for fragment shader execution to be serialized within a tile works well. On other hardware, I expect the cost of serializing those invocations to be much higher. One reason we haven't done deep benchmarking on the Vello side is that our performance story is far from done. We know one current issue is the use of device atomics for aggregating bounding boxes. We have a prototype implementation [2] that uses monoids for segmented reduction, and that looks like a nice improvement. Additionally, we plan to do f16 math (which should be a major win especially on mobile), as well as using subgroups for various prefix sum steps (subgroups are in the process of landing in WebGPU[3]). Overall, I'm thrilled to see this released as open source, and that there's so much activity in fast GPU vector graphics rendering. I'd love to see a future in which CPU path rendering is seen as being behind the times, and this moves us closer to that future. [1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/dawn/features/pixel_local_storage.md https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da... [2]: https://github.com/linebender/vello/issues/259 https://github.com/linebender/vello/issues/259 [3]: https://github.com/gpuweb/gpuweb/issues/4306 https://github.com/gpuweb/gpuweb/issues/4306