Hello I have added the comment of one of the developper involved in the vector rendering in the EFL. It is inlined below
Hope this helps regards Vincent Torri On Wed, May 22, 2019 at 3:55 AM suzuki toshiya <mpsuz...@hiroshima-u.ac.jp> wrote: > * output: efl_gfx > If I can spot the location of the SVG document parser, the > rendering of parsed SVG is done by _efl_gfx_path_XXX() in > src/lib/efl/interfaces/efl_gfx_path.c > ( > https://github.com/Enlightenment/efl/blob/master/src/lib/efl/interfaces/efl_gfx_path.c > ) > > There is a comment "code adapted from enesim which was adapted > from moonlight sources". Are they based on FreeType2? It has evolved a bit. As we support dynamic behavior, we have an intermediate representation in the form of efl_canvas_vg_node. In the case of path information, it is handled by efl_canvas_vg_shape ( https://github.com/Enlightenment/efl/blob/master/src/lib/evas/canvas/efl_canvas_vg_shape.c ). This is then converted to an Ector primitive (this offer the capability to "deduplicate" path computation, compute them in another thread/on GPU and cache them). Ector then use Freetype sw_ft_grays_raster to generate the span line in ector_software_rasterizer.c ( https://github.com/Enlightenment/efl/blob/master/src/lib/ector/software/ector_software_rasterizer.c ). There is quite a lot of potential speed improvement from our perspective in the higher part of our use of Freetype. Maybe a small amount also in Freetype API (If we could get RLE encoded span line, that would be quite nice). But overall our current level of performance in software is above our goal, so our work on this as slowed down. We have some more improvement to do on the GL part and might be a more active part of our work in the near future. > If I'm asked to rewrite whole of elf_gfx_xxx() to fit FreeType2, > simply I would respond "oh, too big, please modularize the > part just to support SVG, I would reconsider after seeing it". > Is it easy for EFL expert? Our current use of freetype API is pretty limited. We do care of doing the full rendering ourself as this enable animation support more easily (We want to be able to have a representation the loaded SVG in the form of object that the user can manipulate directly). I am not sure that the goal of Freetype and EFL in this would really align. Still, if there was a way to reuse a simple SVG parser, we would likely invest the time to do so, just because it will reduce the amount of code we have to maintain. We would also be interested in evolution of SW_FT_DEFINE_RASTER_FUNCS that provide RLE encoded data. Even if it is not matching exactly our current format, improving our code to use a new format with this kind of information would be something we would do easily. Rendering vector graphics fast is a hard problem. Freetype current code base has helped us a lot to get there and we would definitively look at improvement provided by Freetype when it could help us. In general, we do see vector graphics being slower because each step has different constraint and require different strategy. I mean by that, that generating span line is very CPU intensive, but low in memory usage and so can be easily scaled on multiple thread. If we manage to not do this computation quickly and not more than necessary, in simple form (one layer), we can get close to bitmap rendering if not faster (as we use RLE as input instead of bitmap, we have a reduced memory bandwidth in that case). In case of multi layer shape, the complexity of not rendering span line that overlap each other would be the greatest improvement we could do in performance as this would reduce the memory bandwidth required for the blitting step and make it close to bitmap rendering. Maybe something that would also be necessary for Freetype and an area of potential shared use. Anyway, improving vector graphics speed is something we are interested in and if we can reduce our code size, that is even better :-) _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
