slaylines / canvas-engines-comparison Goto Github PK

latest canvaskit-wasm ^0.35.0 has a beast webGPU surface and new CanvasKit.RuntimeEffect

by using custom vertices array and a single uniform color it can spin 1M quads of varying size and positions no problem,

Varying color quads (change color every quad) spins 50k-100k comfortably even if you recompile shader every few hundred passes.

It goes something like this:

 const spiralSkSL = `
    uniform float4 in_colors0;
    half4 main(float2 p) {
        return in_colors0;
    }`;

 const effect = CanvasKit.RuntimeEffect.Make(spiralSkSL);
  let shader = effect.makeShader(
      [
          1, 0, 0, 0.8
      ]);
let vpaint = new CanvasKit.Paint();
vpaint.setShader(shader);

let allPoints = [];
const addPoint = (bbx, bby, bbw, bbh,) => {
    allPoints.push(
        bbx, bby,
        bbx + bbw, bby,
        bbx, bby + bbh,

        bbx + bbw, bby,
        bbx, bby + bbh,
        bbx + bbw, bby + bbh);
}

  function drawFrame(canvas) {
            canvas.clear(CanvasKit.TRANSPARENT);

            allPoints = [];
            let x0 = 0;
            let y0 = 0;

            vpaint.setShader(effect.makeShader([
                1, 0, 0, 0.8
            ]));

            for (let j = 0; j < 100000; j++) {
                addPoint(x0, y0, 3, 3);
                x0 += 4;
                if (x0 > 2000) {
                    x0 = 0;
                    y0 +=4;
                }
                if (j > 1 && j % 10000 === 0) {
                    let vertices = CanvasKit.MakeVertices(CanvasKit.VertexMode.Triangles,
                        allPoints, null, null,
                        false /*isVolatile*/);
                    canvas.drawVertices(vertices, CanvasKit.BlendMode.Dst, vpaint);
                    allPoints = [];
                    
                    vertices.delete();
                    shader.delete();
                    shader = effect.makeShader([
                        Math.random(), Math.random(), Math.random(), 1
                    ]);
                    vpaint.setShader(shader);
                }
            }
            surface.requestAnimationFrame(drawFrame);
        }

        surface.requestAnimationFrame(drawFrame);
}

Not to mention that this way you will have all skia infrastructure along with font manager.

Canvaskit source has a lot of great examples;

I'd love to see how GSAP stacks up against the other three!

https://greensock.com/gsap/

You could try using StageGL (GPU based) with CreateJS

this.stage = new createjs.StageGL("canvas");

and then you need to cache() the rectangles so they are bitmaps

rect.cache(0, 0, size, size);
this.stage.addChild(rect);

Another popular library that would be interesting to compare with.
https://konvajs.org/

Because of the way the DOM benchmark is written – by constantly updating the style value in a rAF – these updates are performed on the main thread and are constantly recalculating styles.

Consider running the animations via WAAPI Animations or CSS Animations instead, so that the browser can try and run these on the compositor.

I have done so here and can PR these changes:

• https://bramus.github.io/canvas-engines-comparison/dom-waapi.html
• https://bramus.github.io/canvas-engines-comparison/dom-css.html

I am creating an online graphic editor similar to Figma, and I want to know the performance bottlenecks encountered by different rendering engines when scaling and panning large scene graphs.

I want to start by saying thanks for the excellent work you've done. It's been a valuable tool for me.

I'd like to suggest a change regarding how the count number is stored. Currently, you're using localStorage, which caused an issue for me. I tried setting the count to 1024000, which led to a crash as expected. However, what's more concerning is that even after reloading the web page, it continued to crash repeatedly. Due to JavaScript's single-threaded nature, it is difficult to change the count to a smaller number.

Could you consider storing the count in an alternative approach such as URL search parameters? This change might help prevent such crashes.

I think another important factor that I'm noticing is the initialisation speed. I am noticing the Two.js example takes a long time to initialise at 5000 items.

Would be interesting to see how long it takes each library to draw their first frame.

The example with Scrawl-Canvas is broken. It's hidden from the menu but available via direct link: https://benchmarks.slaylines.io/scrawl-canvas.html

Possible problem: Scrawl-Canvas script expects the canvas to be already present on the page.
Also consider refactoring the script — there are a lot of commented lines.

Three.js supports instancing, see: https://threejs.org/examples/?q=instanc#webgl_instancing_performance

This could potentially be offered as a means to render in three.js?

The FPS Meter widget is updated via rAF. While not a problem in itself, this is causing issues for WAAPI/CSS animations in some browsers (see #69 for these tests).

In Blink (Chromium), the presence of a rAF will cause the animations – which already happened on the compositor – to also happen on the main thread because you could query for style values inside the rAF. Because of this, WAAPI/CSS animations perform worse when the FPS Meter is present.

See https://bramus.github.io/canvas-engines-comparison/dom-waapi.html for an implementation that allows disabling the FPS Meter widget.

This is great, but I notice on a retina screen that paper.js auto-scales to 2x resolution while the other ones don't, which makes the comparison unfair in that case. I'd like to see how they all compare at 2x or have the option to switch it off... thanks for doing this!

Awesome work!

It would be cool to see:

• p5.js
• pts.js

It might be cool to do the comparison with some SVG engines, too. Some of these canvas engines also do svg, so that might be a good side-by-side comparison.

Can you add phaser.js too?