Look into setting up multi-threading by giving each thread a context

[Ed94]

There is a heavy performance bottleneck in iterating the text/shape/glyphs on the cpu (single-thread) vs the actual rendering (if doing thousands of drawing commands)

• draw_text can provide in the context a job list per thread for the user to then hookup to their own threading solution to handle.

• Context would need to be segregated into staged data structures for each thread to utilize

  • This could converge to the singlar draw_list on a per layer basis. The this would keep the issuing of gpu commands single-threaded unless, its assumed the user is going to feed the gpu the commands & data through separate threads as well (not ideal ux).
  • How the contexts are given jobs should be left up to the user
    Failed Attempts:

• Attempted to chunk the text to more granular 'shapes' from draw_list before doing the actual call to draw_text_shape. This lead to a larger performance cost due to the additional iteration across the text string.

• Attempted to cache the shape draw_list for future calls. Led to larger performance cost due to additional iteration in the merge_draw_list.

  • The shapes glyphs must still be traversed to identify if the glyph is cached. This arguably could be handled in shape_text_uncached, however that would require a significan't amount of refactoring to identify... (and would be more unergonomic when shapers libs are processing the text)