Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

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
<address@hidden> 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 :-)