<commit_before>Issues:


   File and type names
   --------------------
    The naming scheme of files vs objects is bad. Files are all named
    underscore_style, where as classes are named PascalCaseStyle.
    Should make this consistent. Worse, some situations, the name
    ordering is backwards for example freetype_font.[ch]pp defines the
    class FontFreeType. Also, a number of base classes are defined in
    files without the _base suffix, for example FontBase is define in
    font.hpp.

   Text
   --------------------
     The import of WRATHFreeTypeSupport.[ch]pp into freetype_util.[ch]pp
     is a cesspool of ugliness and misery. It desperately needs a cleaning
     up or just a total rewrite. The class geometry_data and point_type
     are utterly unnecessary as are all the LOD methods hanging around.

     We should FreeType to load the -raw- glyph instead via the flags to
     FT_Load_Glyph:
        FT_LOAD_NO_BITMAP | FT_LOAD_NO_HINTING |
	FT_LOAD_NO_AUTOHINT | FT_LOAD_NO_SCALE |
	FT_LOAD_LINEAR_DESIGN | FT_LOAD_IGNORE_TRANSFORM
     and then fetch the scaling factors (face->units_per_EM). Additionally,
     we can fetch the freetype data with likely lots less pain than we
     are now doing if we make use of the function  FT_Outlint_Decompose.

     The class GlyphDatabase is kind of icky since there should be only one
     and to make it thread safe requires locking which means that it is a
     single locking point. Atleast it is only used to fetch/create Glyph
     values and not for formatting.

     We should support sub-glyphs. This requires tweaking to the interaces:
     FontBase, Glyph, GlyphCache and GlyphDatabase. Supporting sub-glyphs
     might let the curepair glyph rendering work on more glyphs.

  GlyphSelector
  --------------------
       GlyphSelector is of questionable value in FastUIDraw since
       glyph selection is closely tied with layout and FastUIDraw
       is supposed to do JUST drawing. However, taken to an extreme
       also means that all of the layout data in GlpyhLayout except
       for m_pixel_size is not needed either.


  To Uber shader or not
  ---------------------
     The GL backend uses an uber shader. We need to also implement so that a
     non-Uber shader is used and perform benchmarking to see if using an uber
     shader is called for. For loads that draw the same stuff the same way,
     the Uber will lose always, but for complicated, the Uber shader will win
     more the more complicated the scene. However, until benchmarks are in,
     we do not know(!).


  GL ickiness
  --------------------
   A number of dtor's in the gl_backend need a GL context
   to operate. However, these objects are reference counted
   and thus their dtors can happen outside of the GL context
   that created them being current. The way out is to have a
   concept of "GL context worker" where functors are added to
   the worker and the worker runs these functors "whenever it
   gets a chance" to do so within a GL context.

  Painter
  -------
   It might be a good idea to have special cases (that a backend must
   support) for clipIn, clipOut against rounded rects and also drawing
   rounded rects. The easiest way is additional shaders to draw a
   rounded rect and another to draw its complement.<commit_msg>ISSUES.txt: remove reference to GlyphDatabase which does not exist<commit_after>Issues:


   File and type names
   --------------------
    The naming scheme of files vs objects is bad. Files are all named
    underscore_style, where as classes are named PascalCaseStyle.
    Should make this consistent. Worse, some situations, the name
    ordering is backwards for example freetype_font.[ch]pp defines the
    class FontFreeType. Also, a number of base classes are defined in
    files without the _base suffix, for example FontBase is define in
    font.hpp.

   Text
   --------------------
     The import of WRATHFreeTypeSupport.[ch]pp into freetype_util.[ch]pp
     is a cesspool of ugliness and misery. It desperately needs a cleaning
     up or just a total rewrite. The class geometry_data and point_type
     are utterly unnecessary as are all the LOD methods hanging around.

     We should FreeType to load the -raw- glyph instead via the flags to
     FT_Load_Glyph:
        FT_LOAD_NO_BITMAP | FT_LOAD_NO_HINTING |
	FT_LOAD_NO_AUTOHINT | FT_LOAD_NO_SCALE |
	FT_LOAD_LINEAR_DESIGN | FT_LOAD_IGNORE_TRANSFORM
     and then fetch the scaling factors (face->units_per_EM). Additionally,
     we can fetch the freetype data with likely lots less pain than we
     are now doing if we make use of the function  FT_Outlint_Decompose.
     We should support sub-glyphs. This requires tweaking to the interaces:
     FontBase, Glyph, GlyphCache and GlyphDatabase. Supporting sub-glyphs
     might let the curepair glyph rendering work on more glyphs.

  GlyphSelector
  --------------------
     GlyphSelector is of questionable value in FastUIDraw since
     glyph selection is closely tied with layout and FastUIDraw
     is supposed to do JUST drawing. However, taken to an extreme
     also means that all of the layout data in GlpyhLayout except
     for m_pixel_size is not needed either.


  To Uber shader or not
  ---------------------
     The GL backend uses an uber shader. We need to also implement so that a
     non-Uber shader is used and perform benchmarking to see if using an uber
     shader is called for. For loads that draw the same stuff the same way,
     the Uber will lose always, but for complicated, the Uber shader will win
     more the more complicated the scene. However, until benchmarks are in,
     we do not know(!).


  GL ickiness
  --------------------
   A number of dtor's in the gl_backend need a GL context
   to operate. However, these objects are reference counted
   and thus their dtors can happen outside of the GL context
   that created them being current. The way out is to have a
   concept of "GL context worker" where functors are added to
   the worker and the worker runs these functors "whenever it
   gets a chance" to do so within a GL context.

  Painter
  -------
   It might be a good idea to have special cases (that a backend must
   support) for clipIn, clipOut against rounded rects and also drawing
   rounded rects. The easiest way is additional shaders to draw a
   rounded rect and another to draw its complement.
{'fraction_non_alphanumeric': 0.05951265229615745, 'fraction_numerical': 0.0, 'mean_word_length': 2.788757396449704, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1001964', 'n_tokens_mistral': 1701, 'n_tokens_neox': 1626, 'n_words': 898}