The bug is with canvases that are GPU-accelerated (size > 256x256)

The problem is relate to the fact that the canvas is never consumed (not displayed, never use as an image source). Therefore it's rendering queue is never flushed.

A possible solution would be to force periodic flushing for pages that treat canvases like they're black holes.

Thanks for explanation @junov. 

Could you perhaps elaborate how can the canvas be flushed? Canvas provided in JSFiddle example is visible, but nevertheless memory issue still persists.

Sorry, I looked at the code too quickly.  I opened the fiddle on a computer that did not have a webcam, that's why.

But it is not completely leaky though. After a couple of minutes, memory stops increasing.

It stops on around 750Mb for me as well. But it shouldn't be like that, right? 

On some laptops web app that is running on that tab becomes slow and in some cases tab can not be closed after few mins at all (doesn't response). Also refreshing the page doesn't free up the memory, only closing the tab does.

Is there perhaps a workaround to clean up canvas rendering queue?

Yeah, this is a bug.  My best guess is that we must be filling-up a cache of some sort, and once the cache reaches its limit, RAM stops growing. but video frames are ephemeral so we should not be caching them.

That's just a guess. I'll know more when I start investigating this for real.

Cool, thanks @junov. Looking forward!

Interesting though that it doesn't happen with default canvas size (memory doesn't leak at all).

Just tried on ToT Linux and didn't see any memory buildup on Task Manager;
the code around canvas has change substantially with the LowLatency-related
actions, so it might have been fixed.  Marking it as WontFix tentatively,
konstantin24@ could you try to repro on Canary plz ? Thx