Re: GSOC - Distance Fields

[Alexei Podtelezhnikov]

Jim, Behdad,

Please hold your horses. This is Anuj's GSoC project for this summer.
It is not nice to take it over until September. For now, please let
him explore the field. Feel free to discuss your own implementation in
a separate thread or at least povide some explanation instead of
abrupt "8.8 makes more sense" or "when I was at Google". This is
highly inappropriate as you had your chance to contribute Distance
Fields before May and will have it after September.

Best regards,
Alexei




On Thu, Jun 4, 2020 at 12:39 PM Behdad Esfahbod <behdad@behdad.org> wrote:
>
> Thanks Jim.
>
> A 2.14 representation when 1 unit = 1em is sufficient.  If we are talking 
> pixels then 10.6 or better 8.8 makes more sense.  And I agree that the pixel 
> values are more useful to clients than em values.
>
> On Thu, Jun 4, 2020 at 8:35 AM Jim Van Verth <jvanverth@google.com> wrote:
>>
>> Behdad,
>>
>> Thanks for the pointer to cu2qu, I'll take a look at it. I assume you're 
>> suggesting we use that in place of GrPathUtils::convertCubicToQuads. I 
>> believe in our case we chop at inflections to avoid artifacts from our 
>> resolution independent curve rendering.
>>
>> As far as scale for our SDFs, 1 unit in distance is one pixel. And Anuj, I'm 
>> not sure 2.14 is enough precision in the integer part. It's been a while, 
>> but I believe I got better results with at least 3 bits of integer.
>>
>> On Wed, Jun 3, 2020 at 6:33 PM Behdad Esfahbod <behdad@behdad.org> wrote:
>>>
>>> Jim,
>>>
>>> I see that in your implementation you are converting cubics to quadratic 
>>> spline.  That makes a lot of sense and I support that.  For the conversion 
>>> though, I see a messy piece of code, which is typical of that kind of 
>>> thing.  I like to introduce you to cu2qu algorithm which we designed and 
>>> implemented back when I was at Google.  It has a much simpler algorithm, 
>>> which is very robust by design and has been used in production of thousands 
>>> of fonts in recent years with no bug report whatsoever.  The core algorithm 
>>> is very simple:
>>>
>>>   https://github.com/googlefonts/cu2qu/blob/master/Lib/cu2qu/cu2qu.py#L218
>>>
>>> Here's a highlevel description of the algorithm:
>>>
>>>   https://github.com/googlefonts/cu2qu/issues/10
>>>
>>> This was specifically designed to have very good behavior for encoding the 
>>> results in a 'glyf' table.  But is useful for more general uses as well.
>>>
>>> It would work much better if we break the input curve on cusps if any.  But 
>>> even that has not been an issue:
>>>
>>>   https://github.com/googlefonts/cu2qu/issues/6
>>>
>>> Cheers,
>>> behdad
>>>
>>>
>>> On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod <behdad@behdad.org> wrote:
>>>>
>>>> Hi Jim, others,
>>>>
>>>> Thanks for your input.  I've been meaning to get into the discussion as 
>>>> well but didn't get to.
>>>>
>>>> I support your suggestions: generate from vector instead of bitmap, as 
>>>> well as 8-bit 3.5 fixed point or similar at least as an option.  In your 
>>>> 3.5 fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size?
>>>>
>>>> I think we do want a 8bit representation at least, and possible a higher 
>>>> one.
>>>>
>>>> On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth <jvanverth@google.com> wrote:
>>>>>
>>>>> Forgive me for coming into this late -- a colleague pointed me to this 
>>>>> thread a couple of days ago and I'm just catching up. I work on Skia, and 
>>>>> we've been generating SDFs from glyphs for quite some time now, so the 
>>>>> possibility of just getting them from Freetype is pretty exciting.
>>>>>
>>>>> I hope you don't mind some comments on what we have now. We currently use 
>>>>> the Gustavson algorithm to generate them from bitmaps but it produces 
>>>>> slightly fuzzy results. I have wanted to move to use this algorithm to 
>>>>> generate them directly from the outline which might be useful to you:
>>>>>  
>>>>> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp
>>>>> We use it to store atlased paths at the moment and it produces much 
>>>>> better results.
>>>>>
>>>>> As far as format, we use an 8-bit 3.5 fixed point format, because it 
>>>>> allows us to combine the SDF and bitmap glyphs into the same atlas to 
>>>>> conserve space. There is a sacrifice in quality, but we only use the SDFs 
>>>>> for larger glyphs so it's acceptable.
>>>>>
>>>>> If you would like more details on our implementation please let me know. 
>>>>> I'm looking forward to seeing how this turns out.
>>>>>
>>>>
>>>>
>>>> --
>>>> behdad
>>>> http://behdad.org/
>>>
>>>
>>>
>>> --
>>> behdad
>>> http://behdad.org/
>>
>>
>>
>> --
>>
>> Jim Van Verth | Software Engineer | jvanverth@google.com | 919-210-7664
>>
>
>
> --
> behdad
> http://behdad.org/



-- 
Alexei A. Podtelezhnikov, PhD