In reverse order:
for offscreen canvas. I suggest you can just keep all your geometry and materials in that thread, and exchange messages with the assumption that the worker thread is the owner of graphics primitives. It will be much easier than you think (probably), but of course that’s assuming that you’re starting with the greenfield, if you have a fair amount of existing infrastructure in place - it will be a royal pain for sure.
For the event listener parameters. I mean try every permutation and see if it has any effect. I’m guessing that depending on the flags the internal implementation might dispatch events sooner. That’s just a hunch, and if it turns out to be true - it will heavily depend on the implementation in a specific browser.
Just a bit more thoughts on the subject:
16ms is not so bad, and screens tend towards higher refresh rate as of late, I have a 144Hz display myself, because when I was making an upgrade it was about the same price as my old 60Hz monitor that I was replacing. With that you’re in 7ms domain, and it will probably only improve from there.
I agree that this is no optimal, for something like an FPS or a fighting game it’s really bad, but it’s generally okay for non-fast paced real-time application (games?). Perhaps we will get a better API for low level Input handing as time goes on.