Skip to content
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

Closed
simoncozens opened this issue May 27, 2021 · 5 comments
Closed

Comments

@simoncozens
Copy link
Owner

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.

simoncozens added a commit that referenced this issue May 27, 2021
(Borrowing heavily from serde_derive)
@simoncozens
Copy link
Owner Author

I've actually made quite a bit of progress on this, including the crazy procmacros to get [derive(Serialize,Deserialize)] working. I think it has a lot of potential to make the more tricky serialisations work properly, but I am not sure how well the stateful serialization/deserialization will work. Not that it ever worked particularly well before.

@simoncozens
Copy link
Owner Author

Yeah, I think we're definitely doing this. It's making the GSUB parsing much easier, and actually just makes everything a bit simpler.

@raphlinus
Copy link

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.

@simoncozens
Copy link
Owner Author

No problem. I think I basically convinced myself. :-)

@simoncozens
Copy link
Owner Author

This happened.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants