PhobosLab

You never read their terms of service which is likely why:

* http://phoboslab.org/log/2013/02/how-much-traffic-is-too-much-traffic-for-cloudflare

* https://www.cloudflare.com/terms

Specifically, the Non-html caching bit.

In other words, if you are significant user of bandwidth...Cloudflare will charge you accordingly [and as you can see from the solution in the blog post, it is much cheaper to just rent a dedicated server than go through Cloudflare if you are willing to give up the CDN cache].

Cloudflare doesn't care about anyone using relatively small quantities of bandwidth because even in aggregate, they aren't costing Cloudflare enough to be a problem.

The other part is....

I doubt Cloudflare is paying "sticker price" for its bandwidth. Places like HE.net sell cheap bandwidth @ $.45/mbps. I wouldn't be surprised if Cloudflare has as good or even better rates at every POP they have.

You are probably thinking of the retail price of Amazon's bandwidth [which is like $.10 a GB. To give you an idea, at $600/mo colo with HE.net you'd have about $2,000-$3,000 worth of bandwidth at Amazon's prices depending on the usage pattern].

Just dealt with some of these issues last week in 7drl.

>image-rendering: optimizeSpeed;

In some cases, you will want to scale the images drawn to the canvas, but not the canvas itself. This causes a lot of headache because of image smoothing and is not resolved by the above CSS. The answer is to set the image smoothing property of the canvas context to false. For example:

ctx.mozImageSmoothingEnabled = false;

ctx.webkitImageSmoothingEnabled = false;

Worked great on Chrome and Firefox. For some reason, though, this does not appear to work in Safari. I'm still amazed that something so simple is so hard to accomplish across browsers (after all you're asking to turn off extra, slower functionality). A good article on the intricacies: http://phoboslab.org/log/2012/09/drawing-pixels-is-hard

Yes. Firefox had terrible GC pauses until last year [1]. Chrome processes just a portion of the heap at a time to reduce pauses to a minimum [2].

You can minimize GC by being clever about re-using objects, avoiding waste. The top answer shows how GC happens less frequently when using a setTimeout loop instead of setInterval, I don't know the underlying reason but that was always recommended before requestAnimationFrame came along.

These days you should use requestAnimationFrame whenever available - it allows the browser to plan ahead for a smoother framerate, adjust rate to the device capabilities, and save resources when it's in the background.

[1] http://phoboslab.org/log/2011/08/are-we-fast-yet
[2] https://developers.google.com/v8/design#garb_coll

I've been working with the leaked wipEout source code for a while[1] and I can assure the quality of the Quake source is absolutely stellar in comparison. While Quake's source may not be up to modern best practices, the overall architecture certainly has a lot of structure and thought put into it.

Modifying Quake to run on the Occulus Rift was a breeze[2], compared to the mountains of garbage I have to wade through with wipEout.

[1] https://twitter.com/phoboslab/status/1653707447586922498

[2] https://phoboslab.org/log/2016/05/quake-for-oculus-rift

And it is now possible to play it in modern computers, compiled from source, as reported 4 months ago:

https://news.ycombinator.com/item?id=37082304

“Rewriting wipEout”: https://phoboslab.org/log/2023/08/rewriting-wipeout

As I wrote at the time:
“WOW! Just a `git clone`, download and unpack the .zip with the assets (end of the blog post), type `make` and it compiles on Linux without warnings into `wipegame`, run it and it works first time!” https://news.ycombinator.com/item?id=37086874

Contrary to what many people believe IE9 actually outperforms both FF and Chrome in many aspects. IE10 should be even better.

http://www.phoboslab.org/log/2011/08/are-we-fast-yet

"Of all browsers and systems I tested, IE9 subjectively produced the best results. It seems to precisely synchronize JavaScript execution with the refresh rate: the benchmark runs at exactly 60 FPS on my machine, even though the timer is scheduled every 16 milliseconds, or 62.5 FPS."