10-30fps Performance in Chrome

[rib]

Thanks for making this - I think this might be a really handy tool for practicing maintaining DAS for me!

Although it's actually nice for some practice to be slowing things down I do wonder if there's a performance issue that I'm seeing or maybe this implementation doesn't currently support real-time simulation?

I currently only get about 10-30fps with the default settings. I have i7-67k 4GHz Skylake PC, 32GB RAM plus an GTX 970 GPU. The GPU isn't that high-end but overall the system is reasonably decent, so I'd guess it should be able to easily simulate at 60fps to match the original NTSC NES fps.

A quick profiler recording in Chrome shows frames e.g. taking ~100ms From there the gpu work looks like it's taking trivial amounts of time like 0.2ms Looking at the stack traces on the main thread it looks like multiple frames are being processed in javascript for each frame presented - I'm not entirely sure why that would be the case but in general it looks like the javascript execution is also only taking a trivial amount of time. The rasterizer thread looks like it's saturated so I suppose the issue with the canvas rendering the playfield on the cpu.

Since I have a 4k monitor so I guessed it might just be too high of a resolution and I tried dropping my monitor's resolution right down to 1024x768 just to experiment but was still seeing the same kind of performance.

I wonder if this is currently expected, or if not I wonder if there might be any known tricks for getting things running at a smooth 60fps?

[GregoryCannon]

Thanks for looking into this! The performance also confuses me a lot... I've timed the code a few times and have never found anything that would bottleneck it, and yet the performance is kind of inconsistent. It usually performs at around 60FPS on my computer, but it's far from consistent and wish I knew why.

If you find any potential fixes, let me know on discord (I'll see that faster than on here) and I'll look into integrating them!

[wikedawsom]

Firstly, ensure that hardware acceleration is turned on in your Google Chrome settings. If that's not the issue, then I may be able to look into the canvas rendering functions.

For example, the little decoration in each mino uses multiple separate draw functions, and may be quicker if the minos are pre-rendered and treated as sprites instead of multiple canvas fillRect calls.

Another thing that may need optimized is ensuring any non-moving graphics don't get re-drawn.

[wikedawsom]

Had a chance to review the code that I contributed for drawing prettier minos back in the day, and I can see some room for improvement. Might try generating a sprite-sheet on a hidden canvas with the correct mino colors each time a level transition happens. Then, we should be able to copy the correct mino for each drawn square which brings each pretty mino render down from 4 or 5 fillRect calls to 1, and the whole piece would render in 4 total.

If we want to get really performant, we could pre-render a full sprite for each piece, and draw the current active piece on a separate canvas layered in front of the play field, which lets us get away with 1 clearRect call and 1 fillRect call for each rendered frame on the main canvas. Might help enough to get this running at the correct speed even without hardware acceleration on some machines. We would still need to be able to draw individual minos though, since the board needs to update colors of locked pieces when the level changes.