On Fri, May 24, 2019 at 5:22 PM Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > > On Thu, May 23, 2019 at 10:41 PM Alexei Podtelezhnikov > <apodt...@gmail.com> wrote: > > > > On Thu, May 23, 2019 at 2:10 PM Vincent Torri <vincent.to...@gmail.com> > > 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
