17

It just seems to me that when writing code for dynamic data visualization, I end up doing the same things over and over in different languages/platforms. Now if I had a cross platform language(which I do) and something like a binary version of SVG, I could make my code target that and use/create interpreters for whatever platform I currently need to use it on.

The reason I don't want SVG is because the plaintext part makes it too slow for my purposes. I could of course just create my own intermediary format but if there is something already out there that's implemented by various things then the less work for me!

Peter O.
  • 32,158
  • 14
  • 82
  • 96
user81993
  • 6,167
  • 6
  • 32
  • 64
  • 3
    The correct answer depends on your needs. Did you consider binary versions of XML (which SVG is based on), such as MTOM, EXI, FastInfoSet, etc.? Which features of SVG do you need? Do you need support for paths, common shapes, groups, text, CSS styling, metadata, etc.? – Peter O. Jul 09 '15 at 21:26
  • 1
    gzip your SVG, that's binary and still parses as SVG. Almost nothing about the performance of SVG other than the transmission cost of sending it over a network is down to it being plaintext. – Robert Longson Jul 09 '15 at 22:41
  • 2
    gzip will not yield the same benefits by far. The problem is if you want to combine raster images in your svg a standard JPEG and another used for alpha mask for example. A binary format would half the size of those two images plus a tiny bit. In SVG format the size is much much larger. Consider: `cat /usr/bin/screen | base64 -w0 | gzip -c9 | wc` = 268406, without base64 it's 216816. In some cases it can be much worse than this. – jgmjgm Dec 08 '15 at 19:22

3 Answers3

5

Depending on what you mean by “too slow”, the answer varies:

Filesize too large

Officially, the closest thing SVG has to a binary format is SVGZ, which is a gzipped SVG file with the .svgz extension. All conforming SVG viewers should be able to open it. Making one is simple on *nix systems:

gzip yourfile.svg && mv yourfile.svg.gz yourfile.svgz

You could also try Brotli compression, which tends to have smaller filesize at the cost of more compression time.

Including other assets is inefficient

SVG can only bundle bitmaps and other binary data through base64 encoding, which has a fair amount of overhead.

PDF can include “streams” of raw binary data, and is surprisingly efficient when programmatically generated.

Parsing the text data takes too long

This is tricky. PDF and its brother, Encapsulated PostScript, are also old, well-supported vector graphic formats. Unfortunately, they too are also text at their core, with optional compression.

You could try Computer Graphics Metafiles, which can be compiled ahead of time. But I’m unsure how well-supported they are across consumer devices.

Tigt
  • 1,330
  • 2
  • 19
  • 40
  • +1 for the CGM mention, thanks for the reminder. I did a lot of work in classic Mac graphics - Quickdraw is basically a serialised set of drawing commands like CGM – Andy Dent Aug 13 '21 at 04:55
4

From a comment:

Almost nothing about the performance of SVG other than the transmission cost of sending it over a network is down to it being plaintext

No, that's completely wrong. I worked at CSIRO using XML for massive 3D models. GeoScience Australia did a formal study into the parsing speed - parsing floating point numbers from text is relatively expensive for big data sets, compared to reading a 4 or 8 byte binary representation.

I've spent a lot of time optimising my internal binary formats for Touchgram and am now looking at vector art.

One of the techniques you can use is a combination of

  1. variable-length integer coding and
  2. normalising your points to a scale represented by integers, then storing paths as sequences of deltas

That can yield paths where often only 1 or 2 bytes are used per step, as opposed to the typical 12.

Consider a basic line <polyline class="Connect" points="100,200 100,100" />

I could represent that with 4 bytes instead of 53.

So far, all I've been able to find in binary SVG is this post about a Go project linking to the project description and repo

Update 2023

I found Rive's discussion of their file format where they talk about using a similar approach of variable-length integers.

Andy Dent
  • 17,578
  • 6
  • 88
  • 115
  • But you'd generally send large SVG across a network using some compression algorithm that the browser supports surely! – Robert Longson Aug 13 '21 at 06:31
  • 1
    Not everyone is focused on binary SVG for web rendering! My point on parsing still stands - compression for transmission just adds more decoding time to unpack, then you have to parse the plaintext. That applies to XML or JSON-based formats. – Andy Dent Aug 13 '21 at 20:25
2

Adobe Flash SWF files may work. Due to its previous ubiquity, 'players' and libraries were written for many platforms. The specifications were open and license permitting. For simple 2D graphics, earlier, more compatible versions would do fine.

The files are binary and extraordinarily small.

Charlie
  • 8,530
  • 2
  • 55
  • 53
  • 1
    Great point. There's the awesome Rust-base Ruffle project to mine for code https://github.com/ruffle-rs/ruffle – Andy Dent Aug 13 '21 at 20:31