Skip to main content
M
1m ago

Artboard.draw() takes 8 ms (13X!!!) if mouse is moving?

VERY SERIOUS bug that prevents us from shipping a client project :(

Runtime: LOW LEVEL WASM 2.21.6, but confirmed in 2.23.10 too. Update: seems to happen in high level too, see below.

Platform: 2017 Dual Core Macbook Pro. Note that this happens on an M3 Macbook too, it's just less visible.



When calling draw(), significant slowdowns (10x the ms cost!!) happen if the mouse is moving.

    let startTime = performance.now();
    this.artboard.draw(renderer);
    let endTime = performance.now();
    console.log(`Rive draw time: ${endTime - startTime}ms + Input.hasMouseMoved: ${Input.hasMouseMoved}`);
Rive draw time: 0.8999999999068677ms + Input.hasMouseMoved: false
RiveEntity.ts:112 Rive draw time: 0.6999999997206032ms + Input.hasMouseMoved: false
RiveEntity.ts:112 Rive draw time: 0.6000000000931323ms + Input.hasMouseMoved: false
2RiveEntity.ts:112 Rive draw time: 0.6999999997206032ms + Input.hasMouseMoved: false
RiveEntity.ts:112 Rive draw time: 3.7999999998137355ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 2.1000000000931323ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 3.6000000000931323ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 1.7999999998137355ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 7.600000000093132ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 1.8999999999068677ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 6.7999999998137355ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 0.6000000000931323ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 0.6999999997206032ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 0.8999999999068677ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 0.6000000000931323ms + Input.hasMouseMoved: true
RiveEntity.ts:112 Rive draw time: 1.1000000000931323ms + Input.hasMouseMoved: true

  • It's not my engine update or any of my code (not the Input logic, not the entities update, nothing. It comes from rendering)

  • It's not pointerUp, pointerDown, pointerMove in the StateMachine, which I suspected. Not calling them changes nothing.

  • It's not what happens in the render function before or after draw()

  • It's not stateMachine.advance(), which you'd expect because it processes mouse events..

..it's just draw()!

You will be able to repro it with any low level WASM implementation that checks for the movement of the mouse.



IMPORTANT UPDATE: You can also notice it on your own implementation.

See https://rive.app/community/files/12995-24869-pokey-pokey/

On an older machine, if you don't move the mouse, the framerate is stable.

If you do, it tanks! Note that clicking is fine!

So it's not the low level WASM, it's anything that draws during mouse movement!

5 replies
M
(edited) 1m ago

any thoughts on this guys? Thanks :))

1m ago

apparently might be the same bug me and others have been experiencing for months now - https://rive.app/community/forums/bugs/fsLjspgTHYcR/rive-community-lag/ftI1CpTSDa4w

1m ago

Hi Mattias, You mentioned that you did a similar test on a more modern computer. Can you share the results of that one as well?

Byu the way, that bug you posted was specific to the community files so I don't think it's related to any current runtime issues.

1m ago

Can you also tell me which web runtime you're using? Canvas, webgl (Skia), or webgl2 (Rive renderer). I know that webgl2 can sometimes have performance issues on older hardware.

Can you make that github repo public?

M
(edited) 30d ago

Hey Lance,

Thanks for your reply!

It's canvas, not webgl nor webgl2.


You can find a repo made especially for the bug report here: https://github.com/RiveBug/RiveBug.github.io
You can test it at: https://RiveBug.github.io 

// To test it:
Leave it rendering for a while without moving the mouse. Then move the mouse a bunch without stopping. Alternate between the two for a while.
Click to download a .csv with the results.

Note that:

  • I was wrong, and I don't see any change on M3 (actually, it is sometimes FASTER when the mouse's moving)

  • I can only replicate the issue on my Intel Mac 2017

  • You must test on Chrome because Safari and Firefox don't report microseconds when calling performance.now()