>> 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, wit
> > 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
> 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 hint
>> 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'
> 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.
> It's also been pointed out to me that setjmp/longjmp can be very slow
(eg, 12ms of a 36ms c
Thanks, do you know how much difference the span batching made to
performance?
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?
-Jamie.
On Mon, 28 Oct 2019, 03:22
> > 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 unbou
> Direct rendering using FT_RASTER_FLAG_DIRECT crashed (bug
introduced in version 2.10.0).
Okay, fair enough, I was looking for something
mentioning FT_RASTER_FLAG_CLIP or clip_box.
> Does using clip_box solve it?
Yes, using the clip_box logic from my earlier email. Once again, not
docume
> On Oct 27, 2019, at 18:07, Jamie Dale wrote:
>
> > This is fixed in 2.10.1.
> Good to know. Once again, not called out in the upgrade notes.
Huh? See line 70.
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/CHANGES
> > What is the performance issue?
>
> Seriously, FT_Ou
> This is fixed in 2.10.1.
Good to know. Once again, not called out in the upgrade notes.
> What is the performance issue?
The lack of clamping means that gray_convert_glyph_inner is called
hundreds of times more than it used to be. The may not be noticed on a PC
with a decent CPU, but on a games
> FreeType 2.10 we found that if you use FT_RASTER_FLAG_DIRECT you now *must*
> also use FT_RASTER_FLAG_CLIP and specify a clip_box otherwise FreeType will
> crash.
This is fixed in 2.10.1. What is the performance issue?
It's direct rendering onto a bitmap to get an outline, yeah. It's basically
the same as in this example:
https://www.freetype.org/freetype2/docs/tutorial/example2.cpp
To give a bit more information, in FreeType 2.6 we didn't actually specify
a clip_box nor the FT_RASTER_FLAG_CLIP flag, and FT_Outl
>
>> FreeType 2.6 used to use an unbounded clip_box in the
>> FT_Raster_Params struct, and internally the gray_compute_cbox
>> function would clamp it to a reasonable range.
>>
>> That clamping no longer happens, so you have to do it yourself
>> before calling the function. The docs don't real
> FreeType 2.6 used to use an unbounded clip_box in the
> FT_Raster_Params struct, and internally the gray_compute_cbox
> function would clamp it to a reasonable range.
>
> That clamping no longer happens, so you have to do it yourself
> before calling the function. The docs don't really explain
Right, I think I've found the issue.
FreeType 2.6 used to use an unbounded clip_box in the FT_Raster_Params
struct, and internally the gray_compute_cbox function would clamp it to a
reasonable range.
That clamping no longer happens, so you have to do it yourself before
calling the function. The d
Further investigation shows that gray_convert_glyph_inner is now being
called hundreds of times, whereas in 2.6 it was called once.
-Jamie.
On Thu, 24 Oct 2019, 15:28 Jamie Dale,
wrote:
> Okay, it's FT_Outline_Render that's gotten slower.
>
> Our code is using the same set-up as RenderSpans in
Okay, it's FT_Outline_Render that's gotten slower.
Our code is using the same set-up as RenderSpans in this example:
https://www.freetype.org/freetype2/docs/tutorial/example2.cpp
-Jamie.
On Thu, 24 Oct 2019, 14:59 Jamie Dale,
wrote:
> Scratch that, it seems to be something in the FT_Stroker AP
Scratch that, it seems to be something in the FT_Stroker API that's gotten
slower.
We're continuing to investigate, but let me know if you have any leads.
-Jamie.
On Thu, 24 Oct 2019, 13:04 Jamie Dale,
wrote:
> Hi,
>
> We recently upgraded from FreeType 2.6 to 2.10, and are finding that with
>
Hi,
We recently upgraded from FreeType 2.6 to 2.10, and are finding that with
identical code, things are now running significantly slower (FT_RenderGlyph
seems to be 10x slower).
I tried changing the "interpreter-version" to both 35 and 40 but it made no
difference.
Is there anything else we nee
19 matches
Mail list logo
