Re: GSoC 2022: Alternative Rendering Engines

[Werner LEMBERG]

Hello George,


> I am an individual who would be interested in the project "Integrate
> FreeType with alternative rendering engines" listed on FreeType's
> GSoC page.

Great to hear!

> There were multiple things in the blog post that the entry linked to
> that I found interesting/had questions about.
>
> The blog post mentions "a large constant factor because it’s doing
> complicated exact-area calculations for each pixel" as a performance
> impediment when drawing into the accumulation buffer.  If one were
> willing to settle for fewer gray levels in the resulting image,
> could something like multisampling be used to eliminate the need for
> these area calculations entirely, especially given that SIMD is
> already being used to exploit parallelism?  I'm sure there's a
> reason why this isn't done, but if someone could enlighten me as to
> exactly why I would highly appreciate it.

I think less than 256 levels of gray are a bad idea.  Regardless of
that, you have to compute the intersection of the glyph outline with
pixels.  Maybe there is a misunderstanding on my side, so please
elaborate.

> I would assume the parsing efficiency improvements mentioned in the
> blog post wouldn't really be applicable to FreeType, as parsing in
> such a way would inhibit more complex intermediate processes such as
> hinting that font-rs doesn't seem to do.  Please correct me if I am
> wrong here.

Fortunately, you are wrong :-) Hinting is always applied to the
outline before it gets rasterized.  In other words, font rendering is
not affected by hinting.

> Would use of SIMD entail an approach like that used by pixman, where
> hand-coded assembly is made for each SIMD instruction set
> extenstion?  If so, which extentions would be pursued.  I personally
> would love to try and learn to write optimized routines in assembly
> with less-used extensions like MMX or PowerPC AltiVec, but I was
> curious as to how relevant these platforms are viewed as.

Mhmm.  Having assembly code in FreeType doesn't enthuse me.  This
would be a last resort for hotspots if low-level C programming doesn't
give enough speed.  The more generic the code, the less hassle we have
to maintain it.

> I apologize for how behind I am in the proposal process. [...]

No problem :-)


    Werner