Not using requestAnimationFrame?

[pbiggar]

I'm debugging some performance issues in our app. While looking through the code I saw that bs-tea doesn't use requestAnimationFrame, seemingly by accident.

In scheduleRender, there's a comment:

(* This turns on or off requestAnimationFrame or real-time rendering, false for the benchmark, should be true about everywhere else. *)

Except it's false.

My reading is that the comment is correct, and that as currently set in the code, bs-tea does not use requestAnimationFrame. It seems like it should.

I tried setting it to true locally and got a very different profile for my app - I was observing a rerender on every keypress earlier with the real-time version, and now I see "Animation frame fired" in the chrome debugger, alongside a much better framerate and a profile behaving as you'd expect for requestAnimationFrame.

So I'm thinking you want to set the if statement to true?

[OvermindDL1]

Blah, I always keep forgetting to set that! I wish the BS build system had injection variables like Dune does then I wouldn't forget things like that... ^.^;

Fixed in 64e977f, thanks much!! ^.^;
0.9.1 released.

But yep, that is what it does, false means it re-renders on every change (which won't affect most things speed, but if there are a lot of updates between frames then it sure would), and true means it doesn't call view at all except once per frame update cycle (or not at all if no changes were done). ^.^

[thangngoc89]

I wish the BS build system had injection variables like Dune does then I wouldn't forget things like that... ^.^;

@OvermindDL1 yes it does ! https://bucklescript.github.io/docs/en/conditional-compilation#docsNav

[OvermindDL1]

@OvermindDL1 yes it does ! bucklescript.github.io/docs/en/conditional-compilation#docsNav

Ooo, the custom variables didn't used to exist...

I'm going to open and leave this open to remind me the next time I mess around with that code, it will be great for synchronous testing and benchmarking the loop itself. :-)