Making PNG download faster

[espadrine]

While SVG is simply a function call to generate, another to SVGO compress, and a last one to gzip, PNG follows all of those steps, loads phantomjs, converts the font to base64, includes it in the SVG, resizes the phantomjs window, takes a snapshot, converts it to PNG, and sends that.

I believe we can:

• Keep phantomjs running (avoids startup time and re-computing the font's base64)
• Cache the resulting image in a fixed-sized RAM store, keeping the most used ones around.

[espadrine]

Note: phantomjs doesn't support stdin, so we can either:

1. Use /dev/stdin and fallback to launching the phantomjs process every time on OSes without that file.
2. Use the experimental phantomjs webserver, which only supports 10 concurrent requests (to be fair, the previous choice only supports 1) and requires to choose a port.

It's a bit of a Scylla and Charybdis situation, however choice 2 seems the most reasonable.

[nathany]

The reason for PhantomJS is to maintain consistency between SVG/PNG.

Listening to the end of the Conversation on Tuesday, and I'm still not crazy about using PhantomJS in-process to convert SVG to PNG.

Though I haven't done any profiling to back up my concern, I suspect it will use quite a bit of memory. Once we're production-ready and serving every badge on the Internet, how many GB of memory our our servers going to need?

• @espadrine mentioned the possibility of running a single instance.
• Is there any possibility of using PhantomJS an offline conversion from SVG->PNG for a blank template badge (eg. something like the gradient image for Buckler) that can be further composited without needing a browser engine in memory.

Also, lets have a discussion about what level of consistency between SVG & PNG we require: badges/shields#102 (comment)

[espadrine]

Though I haven't done any profiling to back up my concern, I suspect it will use quite a bit of memory.

Just measured it, about 35MB, 14 of which is shared.

That said, the phantomjs instance isn't run if the image is in the cache.

@nathany I don't know what you mean when you ask whether we can make phantomjs an offline conversion for a blank template badge without needing a browser engine. We can't run phantomjs without the engine inside of it.

[nathany]

Not too bad.

Especially if we are serving badges indirectly (and eg. Travis CI caches the handful of variations) it's probably not as big of a deal as I thought.

[espadrine]

Travis CI would presumably occupy position 1, 2 and 3 of the cache, so phantomjs isn't an issue at all. What would fill the cache are npm versions, for instance.

I think I have understood what you meant: ask phantomjs to provide a generic bitmap output on top of which we place the color and text? Unfortunately I don't see how that can happen.

We can search for an alternative if phantomjs is too big, maybe inkscape or imagemagick. It is probably not fun to install on Heroku.

[espadrine]

Closing this, as Phantom.js is not the bottleneck.