Re: PangoOpenGLRenderer - a tale of code duplication

[Marc Lehmann <gtk-i18n-list plan9 de>]

On Tue, Jul 18, 2006 at 01:31:57PM -0400, Behdad Esfahbod <behdad behdad org> wrote:
> getting it integrated in Pango somewhere.  Next, the only thing you are
> missing is that Pango doesn't expose internal/protected functions just
> yet, because we (Owen actually) didn't want to freeze on an API that is
> not mature enough, and we didn't envision anyone implementing an
> external backend.

Ah. Oh :->

> PangoXft and PangoCairoFc too.  Also, PangoFT2 is not the best backend
> to base your work on, but it works really good for the most part.

Right, it might have been least-effort, because it already creates freetype
glyphs etc. It is not ideal because it has it's own glyph caching which is
overkill, as I have to cache glyphs in textures already so the cache is not
useful.

Basically, the OpenGL backend does everything PangoFT2 does, the
difference is different rendering and the glyph is cached in a hardware
texture.

> If you just send me the list of API you need public (as in
> PANGO_ENABLE_BACKEND), I'll review and make them available.

The only private API function I _currently_ use is:

   void pango_fc_font_get_raw_extents (PangoFcFont *font, FT_Int32 load_flags, PangoGlyph glyph, PangoRectangle *ink_rect, PangoRectangle *logical_rect);

And this might not be needed if I can use font and fontmap classes from
pango (which I had to duplicate right now). Conversely, my duplication of
code probably got rid of lots references to internal functionality.

> If you cleanup and submit your patch, I'll review and commit it to
> Pango.

Unfortunately, "cleanup" is certainly not enough. Some design work is
needed, and I would need some guidance (and probably discussion) and more
support from pangofc.

The issues I can currently see are:

- texture/glyph caching: my code is not optimal: it can never free glyphs,
  i.e. when fonts get destroyed the associated glyphs are not. The only
  way to free the cache is by freeing it completely. The problem of
  allocating rectangular subshapes optimally within 256x256 rectangles is
  a complex one. (requiring the application dveeloper to manually flush
  the cache after many font changes might be an option - ideas?)

- the texture/glyph cache can go away at any time (lost opengl context), but
  there is no nice way to remove the associated glyph info structures
  associated to the fonts, simply because the fontmap manages them but has
  no api to get at the cached fonts. Either the fontmap gets an API to
  iterate over all fonts, or an API that calls a "clear cache" method on all
  fonts. That would get rid of the generation count hack I currently use.
  
- In theory I would only need my own pango opengl renderer. The question
  should therefore only wether I derive from the ft2 renderer or not
  (right now, I'd say not is cleaner, and a small amount of duplication
  w.r.t. freetype glyph drawing is fine).

If it were integrated in pango, most of the problems would disappear, as I
could just use any private interface that is there.

I will put this ("create a opengl renderer within current pango sources") on
my TODO list (that means I will _eventually_ work on it for sure :).

-- 
A: No.
Q: Should I include quotations after my reply?