TLDR. Ok for static, not for animate.

Now that the current story is no longer displaying at a fixed width and scales to fit the browser it might be worth updating the text on the art to a vector format to be readable at large resolutions. Rendered out a 1200px currently it looks a bit shit when stretched.

Note the change in font hasn’t helped, but.

Above: Text stretched beyond 100% – not good. Below @ 100%

Artwork size in general ranges from ~150kb to 350kb depending on detail gradients etc. I’m generally happy with modern browsers pixel interpolation when resizing images and personally feel not much is to be achieved by ramping the average image size up to achieve crisper text. This could also impact load times for viewers, not a fan of the idea.

Not to say that you cannot have hi-res images, but that it should be served only when the device or browser window requires them, either by img srcset 2x,3x or by browser width detection.

Text as SVG, SVGZ

So I’ll probably look to implement SVG text in the revised comic engine. Running as a separate layer on top of the image. While you could embed the image into the SVG, this causes a few problems, most notably the CMS does not recognise importing SVGs as images.

Testing wise exporting text at a larger size ~3300px gave a file size of 100kb. The comparable SVG file gave a filesize of 77kb when SVGZ, 250kb when SVG, so using the gzipped variant will be the go.

SVGZ Crisp as a motherfucker.

There are many additional processes that could be run for optimising I’m sure – but I don’t have the time or enthusiasm to continually run through a who series of steps each time I want to output. At best I want the CMS to take one hi-resolution page of art, export to reduced sizes that will be chosen depending on requirement, then load the comparable FILENAME.SVGZ to overlay the relevant FILENAME.JPG.

Looks promising though will look at in further when able.

EXCEPT IT IS NO GOOD FOR WHAT I WANT

Didnt think about animation. SVG is not pixel based it does not play nice with animate(); Kills things dead.

I ran some tests with a static svgz overlay, with text fading out / replace / fade up upon the slide transition occurring but it just looked NAFF. Animating over the top of a static SVG also proved a performance hit. So no go.

NEW APPROACH

I will look to use the fallback of a higher-rez text file overlay with filters e.g.  filter: contrast(1.2); see how that goes…

WRONG ASSUMPTION, RIGHT APPROACH

Ok, turns out the SVG works if handled the right way. The performance hit was not from the SVG, but from the nested div with background image. Trying to animate the outer div with image + inner div with text was the issue. I found this when I swapped out the svg for the png image and had exactly the same issue.

How to fix? Use CSS3 multiple background image functionality instead, using the svgz as second url() proved to have no deal-breaking performance hit – cool.