Changes

• 8f47563: I refactored the code base so that text renderers have their own vertex buffer objects which they write to. Should hopefully improve performance when rendering multiple text objects.
• ef4a97f: Did some more refactoring, but this time to improve the layout structure I have. I refactored text renderers a little more so they’re now font-specific rather than text-specific. Also the layout system allows for multiple available fonts and sizes via separate text renderers.

Next Steps

1. The layout system is kind of like absolute positioning right now. I want to implement a more flexible layout system that allows for relative positioning and alignment.

(My favorite devlog so far)

Changes

• 7c7cefe: I added the HDMX table - just for funsies.
• 5eb379b: I did some basic work on the render pipeline so I could actually start rendering glyphs. I did a really messy merge right before this, so I can’t really explain the details of the changes.
• c227220: I fixed the parsing for the glyf table. There was barely anything done correctly when I first wrote it, but I had no way of telling until I tried rendering. This took WAY TOO LONG. I think the core of the issue was that x- and y-coordinates are stored as deltas, not absolute values. I refactored the codebase to hold contours rather than raw points, so that may have somehow solved part of the issue too.
• bf3d0c9: I realized I needed to use a LineList rather than a LineStrip to render the contours properly. A LineStrip connects the last point to the first point automatically, which is not what I wanted (it would connect points from different contours).
• efbef46: I completely forgot that I had to handle bezier curves in the glyph rendering. So I added that functionality in. It seems to be working fine now. I do need to find a way to dynamically calculate a decent precision for the curves.

Next Steps

1. Fill in the glyphs so they’re not just outlines.
2. Implement rendering of composite glyphs.
3. Implement rendering multiple glyphs (i.e. words, sentences).

Changes

• 375abc7: I decided that I’m going to write my own font parsing library. I saw Sebastian Lague’s video on font rendering and it inspired me to try it out myself. I created some basic structs and functions that will help me parse font files and extract glyph data. I’m using MacOS’s /System/Library/Fonts/Times.ttc as my test font file for now.
• ad91bfd: I implemented basic parsing, so I can now parse the TTC data to get a header, and table directories. Each table directory is furhter parsed to get table records. I’m currently working on parsing the ‘cmap’ table to get character to glyph mappings. I’ve completed cmap subtable format 0 and 4 so far.

Next Steps

1. Complete parsing of cmap table by implementing format 2, 6, 8, 10, and 12, 13, 14. I’m considering only doing format 4 and 12 for now since they cover most use cases.
2. Start work on next table to parse, likely ‘glyf’ table to get glyph data.

(Small, but extremely significant change)

Changes

• 1bc896d: I implemented the _adoption_agency function which means a tags (along with all the other formatting tags) are now being properly serialized. Honestly I’m super sceptical about this implementation but it seems to be working fine for now. I’m too scared to test it.

Next Steps

1. Possibly a deserialization to serialize the DOM into HTML.
2. Actually start on rendering the DOM?

(I keep forgetting to devlog)

Changes

• f0f4b470: I decided that my old implementation of some of the structs in the HTML specification was not very good, so I rewrote them. This should make future changes easier. Along with this, I started working on the HTML parser again - this time on the tree construction stage.
• 951e074e: I completed the first 2 insertion mods states in the tree construction stage of the HTML parser.
• db893cd: Not very eventful, I just added a few more insertion modes to the HTML parser’s tree construction stage.
• 19f26fe: I added 2 more insertion modes (6 total now), and also properly implemented a function that I’ve been meaning to implement for a while now (_appropriate_insertion_place). Refactoring my code to support this function was very satisfying.

Next Steps

1. Continue implementing more insertion modes for the HTML parser’s tree construction stage.

Changes

• f7eec2d: I added some serialization functions to all the new URL-related structures, refactored the URLPath structure to be more representative of the specification, and integrated the new URL infrastructure into my existing HTTP client code.

Next Steps

• Implement the HTML parser (for real this time)

Note

The next devlog is probably gonna be a BIG one, like 5+ hours minimum (most likely) - given the fact that the HTML parser specification is just so LONG. I’ve been reading through it and the main state machine literally has 80 states and that’s not even the entire specification because there’s probably a billion utility functions and side quests I’ll have to go on to implement it right.

Changes

• 47f712d: Little bit of work on the HTML spec.
• a849fb1: I was trying to implement the URL specification but turns out I need to implement a host spec and for that I need to implement IPv4, IPv6 and a couple other things. So I’ve implemented IPv6, but this devlog has been mostly just busy work that doesn’t have much immediate benefit to the project.

Next Steps

1. IPv4, opaque and domain parsing (basically, finish up host parsing as a whole)
2. URL parsing (I need to finish host parsing for this)

Changes

• bc11bca, 076345e: I added basic DNS resolution so you don’t have to type in IP addresses when sending requests, and can just write a domain/hostname
• 17ad97c: I abstracted streams away into a trait allowing me to implement a new kind of stream which supports TLS, which means I can now send and receive responses with HTTPS!

Next steps

1. DNS caching and cache invalidation
2. Maybe some work on the rendering?

Changes

• 0784aeb: Started work on the HTTP client that will be sending requests and receiving responses. The next commit should have the actual sending moved into a separate function so that different HTTP Protocols can send requests differently.

• ba895e8: I added integrity checks to requests, different send methods depending on protocol, basic response decoding (only enough for HTTP/0.9 for now), and a basic Client struct so you can specify an address once and send requests to it multiple times

Next Steps

1. Implement response handling for HTTP/1.0 and HTTP/1.1
2. Look into adding support for HTTPS