Re: [ft-devel] GSoC: OT-SVG update and a performance issue
> > Why is it an issue even with clipping? [...] Not a big issue. Such inaccuracies are rare, but when they do pop-up, the inaccuracy isn't a problem. The same happens with Cbox calculation in traditional glyphs and we are fine with it too. :) The glyph will still land up at the right place. > [...] The clipped bounding box can be > very well estimated as an overlap of (1) clipping path bbox and (2) > drawing path bbox. This should be good enough. > I guess that's an internal detail of bounding box calculation and we are not dealing with that. The library authors or the authors of the graphic backends should deal with this. We just use whatever they provide. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG update and a performance issue
> Technically it isn't rendering it to pixel data. A Cairo recording surface > just records the drawing operations without rendering it to pixels (AFAIK). > Then it uses those recorded operations to find bounds. Why is it an issue even with clipping? The clipped bounding box can be very well estimated as an overlap of (1) clipping path bbox and (2) drawing path bbox. This should be good enough. >> > 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) >> >> This is unacceptable because it defeats the purpose. If the library >> cannot return the bounding box without rendering, just forget it and >> bail from ft_glyphslot_preset_bitmap. You and Behdad did however say >> that say that it is available in some libraries. >> https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00128.html >> >> > * get the bounds >> > * perform any transformations on the bounds if necessary and then preset >> > the slot -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG update and a performance issue
Technically it isn't rendering it to pixel data. A Cairo recording surface just records the drawing operations without rendering it to pixels (AFAIK). Then it uses those recorded operations to find bounds. On Thu, Aug 8, 2019, 9:54 PM Alexei Podtelezhnikov wrote: > > 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) > > This is unacceptable because it defeats the purpose. If the library > cannot return the bounding box without rendering, just forget it and > bail from ft_glyphslot_preset_bitmap. You and Behdad did however say > that say that it is available in some libraries. > https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00128.html > > > * get the bounds > > * perform any transformations on the bounds if necessary and then preset > the slot > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG update and a performance issue
> 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) This is unacceptable because it defeats the purpose. If the library cannot return the bounding box without rendering, just forget it and bail from ft_glyphslot_preset_bitmap. You and Behdad did however say that say that it is available in some libraries. https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00128.html > * get the bounds > * perform any transformations on the bounds if necessary and then preset the > slot ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] GSoC: OT-SVG update and a performance issue
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
