#glows { filter: blur(5px) }
Canvas can be fast but if you step into the unoptimized areas the slowdowns can be substantial. Blurring can slow things down a lot. Drawing strokes with a thickness other than one also seems to be an issue. I had one game running at 10fps on an i7 with fancy 3d card, it ran at 30fps on a $200 arm ChromeBook.
This wee game prototype http://www.fingswotidun.com/ld42/post/ runs fine on fairly modest cellphones but the puff of smoke on death kills performance due to the multiply composite mode not being accelerated.
The only thing you can really be sure of is that drawing images is fast. Untransformed images are very fast, rotated and scaled images, less so but still quite impressively fast.
This http://www.fingswotidun.com/ld42 uses only unscaled images and ran at full FrameRate on an 900Mhz Arm9 Mali400.
For reference. A machine that handles only a few fps on Acolytefight handles 40,000 bunnies on this https://lemon07r.github.io/kha-html5-bunnymark/
https://bugzilla.mozilla.org/show_bug.cgi?id=925025
Looks like Firefox does the blur in software whereas the other browsers do it in hardware, but apparently you can turn on gfx.webrender.all to make Firefox do it in hardware, not that it seems to work for me...
Edit: It's just easier to turn off blur in Firefox always. So I'm doing that. Turns out there is a clever way to detect Firefox from CSS. Thanks so much for the suggestion!
Remember when Microsoft started to move faster then specs with IE? At first, all office applications required IE to work and nobody cared. Then games. Then it was a mess and netscape died. Then it got better again.
Now we have chrome, with google moving faster then the specs. I can't even join a hangouts in my office because google didn't bother to update the plugins (after they forced their own plugin into obsolesce by pushing the chrome extension format as a standard and lobbying firefox to adopt it). Now games. Wonder how long firefox will last this time.
What does that mean?
Netscape, Google, Microsoft and Apple have all been guilty of losing patience and ploughing ahead by adding features to their browsers that aren't fully standards-backed at one point or another, but it's usually the decisions of the market leader that have the biggest impact. Lots of people develop for Chrome and assume it'll work elsewhere as a result, or worse they don't care.
Anyway, someone made a suggestion of what to try in another comment, and turns out it was really easy, so now it's fixed. Firefox just does software blurring which is super slow and so I just had to turn that off entirely for Firefox. So Firefox performance is now okay enough, although still not quite like Chrome.
As a Firefox user, I don't like the results either. But I don't think any of the actors in question are acting in bad faith. Not even the lazy web developers who build Chrome-only games; why should they build shit for me, if they don't want to?
Actually I think Firefox supports them natively now but until very recently it didn't.
companies that move "faster than the standards" always do so under the guise of offering better products faster, but with the actual goal of locking in consumers to later enjoy a monopoly. see sony trying to always come up with a new media device, minidisc, memorystick, etc.
It's exactly the same with Google, they have become the Microsoft from before, being bad guys.
Slowly people are seeing it but they are not going to help by switching browsers it seems, so we are doomed to repeat this.
I would be curious to know where the performance lies and what could be done to improve. I saw on another commend he mentioned how using a css blur was a big performance gain over canvas shadowBlur
Well, the networking's very trivial JSON as WS text frames. Hardest task to do is reason through the X and Y attack direction information. I probably won't do that; others surely will.
But there is an absolute firehose of frame data flying over the wire, I would say maybe 10 per second.
So, my guess is this: the dev only ever tested in Chrome, so they inherently avoided what Chrome is slow at.
It would take a lot of work to write a bot on the raw network data because you're missing the simulation code that applies the actions and so won't know the world state.
There are actually specific lines of code for Firefox, Edge and Safari all through the code. Edge can't draw a line if it's width is bigger than its length, so I had to code around that. Safari and Firefox tell you the wrong mouse button on the mousemove event. Firefox performance improved dramatically when I removed all the alphas from the top objects canvas layer. I've tried lots of different ways to stop the scrolling on iOS and Android, and both required different approaches. It's not due to lack of trying. At some point I just had to give up on Firefox for Linux. No one is paying me to make this game!
I tried using the default AI, and since nobody else was connected I picked "Play vs AI". Apparently the bots also use the same AI... and so they all proceeded to engage in a hilarious (and cute) sped-up standoff dance with each other.
And regarding making my own bot, I originally did mean that to mean figuring out/reverse engineering the world state, etc. This is absolutely trivial because this is computed by the clients so there's no server to headscratch about. But the AI system you're using is several levels cooler.
The only suggestion I'd make is to include a socket.io+etc bootstrap that lets people run bots using Node. A rainy-day project might be a login system that lets people tie bot instances to specific rooms...
I had no idea you'd poked the various browsers. Sorry about joining in the flamewar on that, heh. I (honestly) wonder why FF is so much worse than Chrome :/ I wonder if everyone who had issues was using it on Linux.
This is fun, btw. Thanks for building it. :P
Example: https://zenphoton.com/
My guess is there's some sort of misplaced network hook, introducing latency into OP's event handlers, and it's producing a noticeable side-effect in Firefox, which, perhaps Chrome optimizes for, as a common, anticipated programmer tendency, that gets re-ordered behind the scenes.