This repository has been archived by the owner on May 20, 2022. It is now read-only.
Consider ripping out serde and doing our own ser/deserialization #32
Comments
simoncozens
added a commit
that referenced
this issue
May 27, 2021
(Borrowing heavily from serde_derive)
I've actually made quite a bit of progress on this, including the crazy procmacros to get |
Yeah, I think we're definitely doing this. It's making the GSUB parsing much easier, and actually just makes everything a bit simpler. |
Sorry not to respond earlier (I'm deep in some GPU stuff right now). Yes, it's always fine to roll your own if the standard solution doesn't do quite what you want. |
No problem. I think I basically convinced myself. :-) |
This happened. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
serde is really good, and really helpful. It's got us very far very quickly. But it has some significant frustrations, most notably the fact that it's not designed for random access.
Currently any structure that involves offsets (and now we're coming into handling layout, there are lots of them) requires a nasty process of reading the offset data, reading the rest of the structure, calculating how many bytes we've consumed so far in the structure, reading the rest of the available data into a vec, making a new slice starting of the available data from (offset - where we are), and passing that new slice to a separate deserializer. Serializing structs with offsets is even harder, and involves pulling together (possibly nested) serializations and computing their length, etc. The worse thing is that this all has to be done by hand for each structure. If we had true random access, most of the manual ser/de implementations would go away.
Realistically, we don't need the structure/data format abstraction that serde provides, as we are hardly likely to be serializing fonts to JSON or whatever. (I've tried it, it doesn't work...) So perhaps a custom ser/de would even be simpler.
Would be interested to hear opinions on this, particularly from @cmyr @raphlinus.
The text was updated successfully, but these errors were encountered: