freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] An analysis of Librsvg


From: Cedric BAIL
Subject: Re: [ft-devel] An analysis of Librsvg
Date: Fri, 24 May 2019 09:26:01 -0700

On Fri, May 24, 2019 at 8:56 AM Vincent Torri <address@hidden> wrote:
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?

It could be an improvement. I would have the concern of having to many callbacks triggered if there is only one span in a cell. what do you think?

I am not sure how it would be possible, but if we could directly do the allocation for Freetype and avoid the memcpy that would be neat I think. If it was also reducing the amount of realloc we would do, that would be great. And finally, would it be possible for Freetype to maintain a bounding box of the span line it generated, so that we could avoid walking all the span line one time less.

But don't get me wrong, this are small improvement. Freetype already provide a very quick span line generator for us. It will help, but I think we do have some more improvement to do ourself on how we use this span line. Still, if you make the change in Freetype, it should be easy to roll them in for us, so I won't say no :-)
--
Cedric BAIL

reply via email to

[Prev in Thread] Current Thread [Next in Thread]