Re: [ft-devel] An analysis of Librsvg

[Alexei Podtelezhnikov]

On Thu, May 23, 2019 at 10:41 PM Alexei Podtelezhnikov
<address@hidden> wrote:
>
> On Thu, May 23, 2019 at 2:10 PM Vincent Torri <address@hidden> wrote:
> > > There is a comment "code adapted from enesim which was adapted
> > > from moonlight sources". Are they based on FreeType2?
> >
> > https://github.com/Enlightenment/efl/blob/master/src/lib/ector/software/ector_software_rasterizer.c
> > (If we could get RLE encoded span line, that would be quite nice).
>
> You are already capturing spans generated by FreeType directly. As
> they come sequentiially, this is already as close as it gets to RLE,
> isn't it? RLE is length-color-length-color-etc, which is what a
> sequence of coverage-spans is. Do I miss something about RLE?

The function _rle_generation_cb does too many realloc's:
https://github.com/Enlightenment/efl/blob/master/src/lib/ector/software/ector_software_rasterizer.c#L729
FreeType delivers one span at a time and realloc is called each time.
FreeType can probably deliver an initial fake zero-length span to
communicate the number of cells in the stream. Each cell can produce 1
or 2 spans, so you can allocate memory in larger chunks. Is this worth
it?