Re: FT Performance Regression?

[Jamie Dale]

Okay, so we're saying the bug here is that you needed to provide the clip
flag in FT 2.10, and that omitting that in 2.10.1 gives the same optimal
result as 2.6? If so, then yes, that seems fine.

We won't be upgrading FreeType again soon as I started this process back in
February and don't have time to go through it again for all platforms. Is
the clip rect I've calculated correct?

-Jamie.

On Mon, 28 Oct 2019, 00:16 Alexei Podtelezhnikov, <address@hidden>
wrote:

> > > Does using clip_box solve it?
> > Yes, using the clip_box logic from my earlier email. Once again, not
> documented nor called out in a release note. I've not looked at the code
> for 2.10.1, but if all you've done is fixed the crash when omitting
> FT_RASTER_FLAG_CLIP so that it uses an unbounded clip_box without clamping
> it later (like gray_compute_cbox used to) then you're still sitting on a
> 10x performance regression.
>
> FreeType always calculates and uses bounding box with
> FT_RASTER_FLAG_DIRECT except one corner case when the clip_box is
> *provided*. Indeed, FreeType assumes that the clip_box is actively
> designed to cut parts of the glyph out, not some distant page margins.
> You have to admit that ignoring out of bounds spans is quite easy in
> direct mode, so passing this job on FreeType is lazy. The key concept
> here is that FreeType is not a layout engine it is incorrect to pass
> the page margins to FreeType. So in a nutshell, do not bother FreeType
> with page margins use clip_box *only* to cut parts of a glyph out.
>
> You welcome to argue otherwise.
>