Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

On Fri, May 24, 2019 at 5:22 PM Alexei Podtelezhnikov
<address@hidden> wrote:
>
> 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?

i'm adding Cedric, one of the dev to this thread. Let's see what he says

thank you

Vincent Torri