This adds a new homemade package `pkg/objc` that wraps the Objective-C runtime so that Zig can interface with ObjC. This doesn't have 100% API coverage but all the hard problems (mainly `objc_msgSend`) are done. We can merge this now, start working on ObjC stuff, and expand APIs as we need them.
The `objc` package is of course only available to Mac builds.
This moves the OpenGL renderer out to a dedicated thread. The immediate effect
is noticeably improved FPS under high load scenarios. But the future impact is
also important: (1) required for multiple windows, tabs, etc. one day (2) forced
a refactor to support pluggable renderers.
== Architectural Notes
Windowing events and IO remain on the main thread for now, but I plan to move
IO to a dedicated thread in a future PR. Windowing events have to remain on the
main thread for eternity since some platforms force all Window events onto one
thread.
This is one of the reasons that this will be required for multi-window. As more
windows are opened, the windowing system will send more and more window events
to our main thread, taking more and more time away from other tasks on the main
thread. Windowing events are effectively free, so if the thread is ONLY handling
windowing events, this can scale basically forever.
Further, with OpenGL, each window must have its own "context." A context is the
state used to draw. OpenGL mandates at most one context is active at any given
time _per OS thread_. For multiple windows, this means that a single thread
would have to draw one window at a time in serial. With multiple rendering
threads, each thread can have its own context activated and draw in parallel.
The renderer thread and main thread **do have shared state** and will have some
shared state forever. The terminal screen state for example is shared memory.
An immutable data structure or double buffering would be too expensive (I think,
I'll check one day) so we use a mutex to protect access to the terminal state.
The primary instigator of terminal state change is PTY read. This is the
primary motivator to eventually move IO to its own dedicated thread as well.
As multiple windows come up, each PTY under heavy load conditions will block
only its own thread and hold the lock only for its own terminal state (and
therefore its own renderer thread).
We can continue to optimize critical areas from this point forward though and
lower any contention.
== Performance Notes
I haven't done any hard benchmarking on this, only did some cursory
memory measurements, CPU measurements, etc. I also ran superficial test
programs such as `cat`-ing large files, scrolling through large buffers
in vim, etc.
In any case, it seems that responsivity is generally higher, although it
appears that `cat`-ing large files slowed down by roughly 10%. This is
probably due to the lock overhead with the renderer and optimizing for
higher framerates with this setup.
"Grid" was a really antiquated name when it had both the screen state
AND the renderering functionality tied together. This hasn't been true
for a LONG time and it is long overdue that this is renamed to its
proper name.
This also begins setting up a folder structure to anticipate future
renderers and rendering functionality. I'm not working on any alternate
renderers right now so the interface isn't expected to be good, just
laying out the files in this way.
Most emoji fonts are massive glyphs (128x128, 256x256, etc.). This means
the texture we need to store emoji is also massive. For a 128x128 emoji
font (both Apple and Noto), we can only store 12 emoji before resizing
prior to this commit.
This commit now threads through a max height through to the font face
and resizes the bitmap in memory before putting it in the atlas. This
results in significant savings. The max height is the cell height. We
allow the glyphs to be as wide as necessary due to double (and more)
wide glyphs.
For the unicode emoji test file, the atlas size before and after:
Before: 262 MB
After: 16 MB
