Hi,

I have changed the code to get the bounding box by using a
`cairo_recording_surface' instead of relying on CFF/TFF outline bounding
boxes. The code works great and Bixa Color is being rendered properly too.
I have also changed `ft_glyphslot_preset_bitmap' to work with OT-SVG
glyphs, so now, the slot will be preset at the loading stage.

However, there is one performance concern I have:

Since the bitmap presetting of an OT-SVG glyph can only be done by the
"rendering port", I had to create a hook function called `preset_slot'.
Then I create a wrapper function around it in my `ot-svg' module and this
wrapper function gets exposed via the interface of the `ot-svg' module.
Ultimately, this function gets used in `ft_glyphslot_preset_bitmap' for
presetting an OT-SVG glyph.

This hook function (for librsvg) would work in the following manner:
* create a cairo recording surface
* render the glyph on that surface (you'll have to check whether to render
the whole document or a particular element)
* get the bounds
* perform any transformations on the bounds if necessary and then preset
the slot

At the end of `FT_Load_Glyph' you'll see that it calls
`ft_glyphslot_preset_bitmap' only if `FT_LOAD_RENDER' has not been passed.
Which indicates that `FT_Render_Glyph' shouldn't really care whether
presetting was done or not. In fact, in `ft_smooth_render_generic',
`ft_glyphslot_preset_bitmap' is called again. I have to replicate the same
behavior with OT-SVG. Thus, in `ft_svg_render', I call the preset hook
again to be sure that presetting is done, this is so that I can use the
width/height to allocate memory before calling the render hook. Then in
render hook, once again the same recording surface calculations will need
to be done to get the bounding box (which is necessary for rendering).

So you see, the same thing is being done 3 times. I just need this
information to persist in an accurate manner so I can reuse it instead of
calculating it again and again. I have managed to reduce this to 2 by doing
this:

The preset hook function takes an argument called `cache' (just a name, can
change), if this is set to TRUE, it'll store all of its calculations inside
the state of the rendering port. When `ft_svg_render' calls the preset hook
it'll set `cache' to TRUE, thus all calculations will be stored in the
rendering port's state and then the render hook can just use those. When
`FT_Load_Glyph' calls `ft_glyphslot_preset_bitmap', it'll call the wrapper
function with `cache' set to FALSE, thus, no state gets stored then.

Thus there is a possible repetition here (which is also present in the case
of traditional glyphs). if there's a better way to do this, let me know.
Should we worry about this performance concern?

Moazin
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to