>> > 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. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
