Re: [ft-devel] An analysis of Librsvg

[Alexei Podtelezhnikov]

>> > 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?

You can, of course, reduce reallocs by doubling the memory when
needed. anticipating as many spans as you have already seen...
FreeType keeps track of how many cells/pixels the outline has visited.
Since each pixel is a span itself and possibly a boundary, it gives an
idea about the number of spans. We can communicate this for each band
of scanlines occasionally, because FreeType renders large images in
bands.

> 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.

Presently FreeType delivers one span at a time:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftgrays.c?id=306d2f6ccb5a05eb54c8de7ef07fc5b46f1649a1#n1224
So you can copy directly or borrow our trick 10 lines down for the
sake of API compatibility.

>  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.

FreeType does not keep track of exact pixel bounding box, it relies on
quick control box from from the outline.