Created attachment 107362 [details] [review]
the patch from Tomas Frydrych

just as a comment: this patch allows us to use the PangoFT2 backend without having to copy the font and fontmap stuff over into Clutter itself.

poking.

PangoFT2 would ideally be deprecated as soon as possible. What extensions
need to be made to allow clutter to use cairo for this?

ideally, if we could subclass PangoCairo and override it with our own caching mechanism then PangoCairo would be a better option for us - in terms of reliability and (possibly) portability.

you can see the new GL renderer here:

  http://bugzilla.openedhand.com/show_bug.cgi?id=919

(comments welcome)

ideally, we want our own glyph cache in texture memory as a 8bit alpha texture, to avoid the excessive memory usage of just rendering a layout to a cairo surface and then pushing it to the texture memory.

So, basically you want a render-to-GL cairo backend. (glitz wasn't
really designed for that, since it pretty much takes over management
of GL resources, from what I've seen.)

not really, even though it would be good. :-)

at the moment, we are redesigning the pango renderer, and one option we are exploring is rendering each glyph with pangocairo and populate our GL cache with the image data from the cairo context; then we could render a PangoLayout using the contents from that cache.

ideally, this would allow us to entirely avoid subclassing; Tomas and Neil are looking into it, so I'll leave it to them to comment.

Well, from my perspective, Pango isn't supposed to have glyph caching
or rendering in it any more ... it outsources to cairo. So if you want
to hook into glyph caching and rendering, you have to hook into cairo.

(Not to say that other things aren't possible, but that's conceptually
how it's supposed to work.)

Emmanuele, you should be able to do what you want by just writing a new PangoRenderer that hooks into your own cache and uses pangocairo to render individual glyphs to upload to the cache.  That's much simpler than implementing a fontmap.

(I'm ok committing the patch still, after minor tweaks.  Just that I want to see clutter use pango properly)

(In reply to comment #9)
> Emmanuele, you should be able to do what you want by just writing a new
> PangoRenderer that hooks into your own cache and uses pangocairo to render
> individual glyphs to upload to the cache.

That's effectively what we're doing with the new pango renderer except with FT2. It directly uses the PangoFT2FontMap but has a new renderer as a direct subclass of PangoRenderer. The renderer overrides draw_glyph and uses FreeType to render to a bitmap and then uploads the bitmap to a portion of a GL texture for caching. It uses a hash map to look up the glyph cache based on the font and glyph number which avoids having to apply the patch in this bug but it is potentially slower.

I've just added another patch to the bug to do the same thing using pangocairo instead but I think OH is a bit apprehensive about making Cairo a hard dependency of Clutter.

the new Pango renderer in Clutter trunk is using PangoCairo to draw the glyph and cache it; we are still evaluating performances but eventual issues will be raised in other bugs, so I guess we can close this one as notabug.

thanks Behdad, and thanks Owen.