What is the point of the "compiled state"?
Atemu opened this issue · 1 comments
AFAICT the "compiled state" is the "working state" except that each cursor shape directory is packed up into a zip file called $shape_name.hlc.
In the (probably rather common) case of a converted raster cursor, zipping a bunch of PNGs will only serve to increase their size due to compression format overhead. According to du -sb, an example cursor I just made with a single shape needs 4027 bytes in the working state and 4274 in the compiled state.
The only thing that actually gets compressed in that case are the metadata.{hl,toml} files which are tiny. Even if they were worth compressing, it'd be better to just encode those specific files using gzip as that format is rather easy to work with.
This practice is only beneficial in the case of SVG cursors. In that case, the individual files are rather small already (each on the order of 10^2 - 10^3 bytes) but can be compressed even further. While compression is effective in relative terms here, it is insignificant in absolute terms however.
As a benchmark, all SVGs in the Bibata repo combined are 645KiB on disk uncompressed, 150KiB when tar.gz'd up and 338KiB when individually gzipped (svgz is sort of a thing actually).
I can't remember the last time I cared about anything <1M sitting around on disk.
Couldn't we just use the "working state" as the standard layout? It's much simpler and I think it's quite well designed.
not much apart from the compression benefit on svgs (preferred method)
that's just how I wrote it, tbh. I don't see a reason not to have it.