For the longest time we've been encoding images as Base64 Data URLs in livesplit-core. This was done in order for Web LiveSplit One to easily present the images as URLs. However we don't need this for LiveSplit One on the Desktop. There we currently decode the Base64 Data URL before passing it to the rendering backend. Splits i/o is negatively affected by this as well, as all the images get turned into base64 data urls when the splits are parsed, even though splits i/o isn't even using the images (and even if they did, they might not want them as base64 data urls). And even worse: Not even the Web LiveSplit One needs them as Base64 Data URLs. Instead Web LiveSplit One can just create Object URLs out of the raw memory and use those.
However this all sounds like it would be trivial to switch, but it isn't. We currently serialize the layout states into JSON and the serializer for that will always encode bytes as integer arrays, so instead of the 2 bytes FF0A you end up with the JSON string of "[255, 10]" which takes up 9 bytes. So this is much less efficient than base64 which has an increase of 4/3x. Also the base64 is calculated once in its current form, while the JSON array would possibly be transferred multiple times for a single icon (at least once per component).
What may be a possibility, is that we simply return a unique ID per image and then you can query the raw byte slice from memory via that ID. That is close to already what we do. However that isn't entirely great either as that means the JSON states aren't actually representing "the whole picture" anymore.
For the longest time we've been encoding images as Base64 Data URLs in livesplit-core. This was done in order for Web LiveSplit One to easily present the images as URLs. However we don't need this for LiveSplit One on the Desktop. There we currently decode the Base64 Data URL before passing it to the rendering backend. Splits i/o is negatively affected by this as well, as all the images get turned into base64 data urls when the splits are parsed, even though splits i/o isn't even using the images (and even if they did, they might not want them as base64 data urls). And even worse: Not even the Web LiveSplit One needs them as Base64 Data URLs. Instead Web LiveSplit One can just create Object URLs out of the raw memory and use those.
However this all sounds like it would be trivial to switch, but it isn't. We currently serialize the layout states into JSON and the serializer for that will always encode bytes as integer arrays, so instead of the 2 bytes FF0A you end up with the JSON string of "[255, 10]" which takes up 9 bytes. So this is much less efficient than base64 which has an increase of 4/3x. Also the base64 is calculated once in its current form, while the JSON array would possibly be transferred multiple times for a single icon (at least once per component).
What may be a possibility, is that we simply return a unique ID per image and then you can query the raw byte slice from memory via that ID. That is close to already what we do. However that isn't entirely great either as that means the JSON states aren't actually representing "the whole picture" anymore.