Re: FT Performance Regression?

[Jamie Dale]

> Jamie, could you suggest a documentation enhancement to cover the
difficulty you've experienced?

I think the difficulty was just caused by the regression. Usually you
wouldn't give a clip rect unless you know what you're doing, but the
regression required one to avoid the crash, without any hints about how to
calculate a suitable default.

> This is definitely not a bottle neck

Maybe, but 1/3rd of a function call being spent not doing actual work is
definitely concerning in a world where you only have 33.3ms or 16.6ms to do
all your work that frame.

It looks like setjmp in FreeType is basically used to do exception-like
handling in C, in lieu of using and checking return values?

Looking through the mailing list it seems to come up periodically, mainly
when people are either missing setjmp, or have a really bad implementation
of it.

-Jamie.

On Sat, 2 Nov 2019, 08:37 Werner LEMBERG, <address@hidden> wrote:

> >> Thanks, do you know how much difference the span batching made to
> >> performance?
> >
> > In depends on your program.  Simple scanlines might be delivered at
> > once.  Freetype won't wait for you to process each spam.
>
> Jamie, could you suggest a documentation enhancement to cover the
> difficulty you've experienced?
>
> >> It's also been pointed out to me that setjmp/longjmp can be very
> >> slow (eg, 12ms of a 36ms call was spent in setjmp). Are there any
> >> plans to remove FTs dependence on these functions?
> >
> > This is definitely not a bottle neck, unless the font is crazy
> > complicated <https://fonts.google.com/specimen/Cabin+Sketch>.  If
> > you are paranoid, you can increase FT_RENDER_POOL_SIZE
> > <
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/config/ftoption.h#n398
> >.
>
> This is probably also worth to be mentioned in the docs.
>
>
>     Werner
>
>