Re: fuzzing SDFs

[Anuj Verma]

*> Looks good!  Please submit a Pull Request that Armin (and others) can >
review. *

Done!

The fuzzer already found a bug in the renderer, I have attached a patch
(diff.txt) to
fix this (https://github.com/freetype/freetype2-testing/runs/3213214141).
If you require a merge request instead, then I'll make it tomorrow.

Also, there is a timeout in one of the tests:
240 - truetype-render-i38:oss-fuzz/10398-5653547685773312-timeout (Timeout)
Is there a way to increase the timeout ? As I would like to test this
locally
and confirm that it's just a timeout and not a bug.

*> I think generally there are two options:*









* > > - We do have a few screws at this point to steer how many glyphs
we're > looking at in a single fuzzer run.  We could either use one of the
existing > ones or, if they are to coarse, we could introduce new screws
that > specifically target the SDF mode. > > - Alternatively SDF could get
it's very own fuzzer.  We've already done this > to separate rendering from
utility access;  we _could_ look into further > separating fuzzing
rendering from fuzzing SDF rendering.  Although, that*
*> would be quite a lot of work. *

Seeing how slow the `sdf` renderer is I think the second option would
be better. Dominik recently added the COLRv1 fuzzer, if the process is
similar, then I can work on adding a new fuzzer for SDF.

Thanks,
Anuj
diff --git a/src/sdf/ftsdfrend.c b/src/sdf/ftsdfrend.c
index 420ad496c..6fd104dbf 100644
--- a/src/sdf/ftsdfrend.c
+++ b/src/sdf/ftsdfrend.c
@@ -350,6 +350,8 @@
 error = render->raster_render( render->raster,
(const FT_Raster_Params*) );
 
+if ( x_shift || y_shift )
+  FT_Outline_Translate( outline, -x_shift, -y_shift );
   Exit:
 if ( !error )
 {
@@ -362,9 +364,6 @@
   slot->internal->flags &= ~FT_GLYPH_OWN_BITMAP;
 }
 
-if ( x_shift || y_shift )
-  FT_Outline_Translate( outline, -x_shift, -y_shift );
-
 return error;
   }
 
@@ -506,6 +505,16 @@
   goto Exit;
 }
 
+/* do not convert to SDF if the bitmap is not owned by glyph */
+if ( !(slot->internal->flags & FT_GLYPH_OWN_BITMAP) )
+{
+  FT_ERROR(( "ft_bsdf_render: can't convert bitmap to sdf;\n" ));
+  FT_ERROR(( "bitmap not owned by glyph.\n"   ));
+
+  error = FT_THROW( Invalid_Argument );
+  goto Exit;
+}
+
 if ( !bitmap->rows || !bitmap->pitch )
   goto Exit;
 

Re: fuzzing SDFs

[Anuj Verma]

*> Anuj, there is a lot of documentation in form of READMEs in this
repository to hopefully give you a*
*> high-level idea of how this thing is kind of put together.  I reckon, a
good entry point to probably this*

*> script:
https://github.com/freetype/freetype2-testing/blob/master/fuzzing/scripts/custom-build.sh
;
*
*> just run it and it will prompt you for details :)*

Thanks!, I did check it out and I think simply adding the new render modes
to the render mode
list should be sufficient. The first line (`{ FT_LOAD_NO_BITMAP |
FT_LOAD_TARGET_NORMAL, FT_RENDER_MODE_SDF }`)
is to use the `sdf` module for rendering and the second (`{ FT_LOAD_RENDER
| FT_LOAD_TARGET_NORMAL, FT_RENDER_MODE_SDF }`)
is to invoke the `bsdf` module since it requires bitmap input. Please check
it out, if there are other
things required please let me know, I'm attaching the diff below.

diff --git a/fuzzing/src/visitors/facevisitor-renderglyphs.cpp
b/fuzzing/src/visitors/facevisitor-renderglyphs.cpp
index abcfb2a..c1871a0 100644
--- a/fuzzing/src/visitors/facevisitor-renderglyphs.cpp
+++ b/fuzzing/src/visitors/facevisitor-renderglyphs.cpp
@@ -27,7 +27,9 @@
 { FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_LIGHT,  FT_RENDER_MODE_LIGHT  },
 { FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO,   FT_RENDER_MODE_MONO   },
 { FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_LCD,FT_RENDER_MODE_LCD},
-{ FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_LCD_V,  FT_RENDER_MODE_LCD_V  }
+{ FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_LCD_V,  FT_RENDER_MODE_LCD_V  },
+{ FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_NORMAL, FT_RENDER_MODE_SDF},
+{ FT_LOAD_RENDER| FT_LOAD_TARGET_NORMAL, FT_RENDER_MODE_SDF}
   };

Thanks,
Anuj

Re: A few questions about the new SDF render

[Anuj Verma]

> One more question: Do you have a recommended
> font size for the SDF render?

It will probably depend on the font, I’d say you won’t
need more than 128, but I can be wrong.
If you can, please build the demo program and see
what works for you. Also, there are some imperfections
in the ‘sdf’ renderer so you might want to use
‘bsdf’. Please check the ‘ftsdf’ demo program, it has everything
required.

Re: A few questions about the new SDF render

[Anuj Verma]

Hello Zhuyie,

*> 1. From the comments in ftsdf.c, [...]*

The implementation only supports single channel SDF. So the documentation
for ` FT_RENDER_MODE_SDF ` is correct. Thanks though, the comment might
need some editing.

*> 2. Are there any tutorials about [...]*

The output is a pretty basic SDF, there is a comment on how to convert the
output
values to unsigned pixel values (
https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/include/freetype/freetype.h#L3324
).
As for tutorial, you can use the `ftsdf` demo program implementation in the
shaders.
It should work exactly the same.
https://gitlab.freedesktop.org/freetype/freetype-demos/-/blob/master/src/ftsdf.c#L598

Thanks,
Anuj

Re: new release?

[Anuj Verma]

* > I will push the positioning fix in a few hours and the moire pattern >
is an artifact of our 16-level graphics blender. Looks really good >
indeed, we only need to improve the speed. *

Thanks for working on this. Since the output is only 8-bits now I
might be able to use more bits for precision and thus reduce
artifacts. As for performance, I see that I'm doing way too many
small allocations which do not serve any purpose in the current
implementation. I'll try to work on these things.

Anuj

Re: new release?

[Anuj Verma]

*> Can this be accomplished by a public macro? Probably not, because the*

*> spread is not a public value, right? We can simply give an explicit*

* > formula in the docs. *

Yes, spread is not a public value. I have already added the pseudo code in
`freetype.h` near `FT_RENDER_MODE_SDF`. I think it should be good as
long as we don't change the output format.

Re: new release?

[Anuj Verma]

*> It seems that the patch hasn't been applied yet.  Can we please go*

* > forward so that it becomes part of the next release? *

I'm attaching the two patches below, as decided the output will now be
unsigned with [0, 128) corresponding to negative and inside and (128, 255]
otherwise.  Although the conversion back to pixel values isn't too
complicated
I think we should add one API function to do the conversion for the
client.  If you
agree let me know where to add it.

Thanks,
Anuj
diff --git a/ChangeLog b/ChangeLog
index 0d0e8f3bc..b294a54ee 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,32 @@
+2021-06-06  Anuj Verma  
+
+   [sdf] Use 8 bits for final SDF output instead of 16bits.
+
+   Since 8bits is enough to represent SDF data we no longer require 16bits 
for  this
+   purpose. Also, we now normalize the output data to use the entire 8bit 
range
+   efficiently. For example: if we use 3.5 format with a spread of 1 we 
basically only
+   use the first 5 bits. By normalizing we can use the entire 8bit range.
+
+   * include/freetype/freetype.h (FT_Render_Mode): Update the description 
for
+ `FT_RENDER_MODE_SDF` regarding this change.
+
+   * include/freetype/ftimage.h (FT_Pixel_Mode): Removed 
`FT_PIXEL_MODE_GRAY16`
+ since no longer required.
+
+   * include/freetype/fttypes.h (FT_F6Dot10): Removed since no longer 
required.
+
+   * src/sdf/ftsdfrend.c (ft_sdf_render, ft_bsdf_render): Allocate 8bit 
bitmap instead of
+ 16bit buffer.
+
+   * src/sdf/ftsdfcommon.h (map_fixed_to_sdf): Added function to convert 
16.16
+ distance value to our desired format.
+
+   * src/sdf/ftsdf.c (sdf_generate_with_overlaps, 
sdf_generate_bounding_box):
+ Modified to use the new `map_fixed_to_sdf` function and also use 8bit 
output
+ buffer.
+
+   * src/sdf/ftbsdf.c (finalize_sdf): Output to a 8bit buffer instead of 
16bit buffer.
+
 2021-06-02  Ben Wagner  
Werner Lemberg  
 
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index 03438b531..ebb129f71 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -3302,19 +3302,46 @@ FT_BEGIN_HEADER
* pixels and use the @FT_PIXEL_MODE_LCD_V mode.
*
*   FT_RENDER_MODE_SDF ::
-   * This mode corresponds to 16-bit signed distance fields (SDF)
+   * This mode corresponds to 8-bit signed distance fields (SDF)
* bitmaps.  Each pixel in a SDF bitmap contains information about the
* nearest edge of the glyph outline.  The distances are calculated
* from the center of the pixel and are positive if they are filled by
-   * the outline (i.e., inside the outline) and negative otherwise.  The
-   * output bitmap buffer is represented as 6.10 fixed-point values; use
-   * @FT_F6Dot10 and convert accordingly.
+   * the outline (i.e., inside the outline) and negative otherwise. Check
+   * the note below on how to convert the output values to usable data.
*
* @note:
*   The selected render mode only affects vector glyphs of a font.
*   Embedded bitmaps often have a different pixel mode like
*   @FT_PIXEL_MODE_MONO.  You can use @FT_Bitmap_Convert to transform them
*   into 8-bit pixmaps.
+   *
+   *   For @FT_RENDER_MODE_SDF output bitmap buffer contains normalized
+   *   distance values that are packed into unsigned 8-bit buffer.  To get
+   *   pixel values in floating point representation use the following
+   *   conversion:
+   *
+   *   ```
+   *   
+   *
+   *   ...
+   *   FT_Byte buffer = glyph->bitmap->buffer;
+   *
+   *   for pixel in buffer
+   *   {
+   * <`sd` is the signed distance and spread is the current `spread`,
+   *  the default spread is 2 and can be changed>
+   *
+   * float sd = (float)pixel - 128.0f;
+   *
+   * 
+   *
+   * sd = ( sd / 128.0f ) * spread;
+   *
+   * 
+   *   }
+   *
+   *   ```
*/
   typedef enum  FT_Render_Mode_
   {
diff --git a/include/freetype/ftimage.h b/include/freetype/ftimage.h
index e3cc68f6c..66a8b89aa 100644
--- a/include/freetype/ftimage.h
+++ b/include/freetype/ftimage.h
@@ -157,13 +157,6 @@ FT_BEGIN_HEADER
* in font files according to the OpenType specification.  We haven't
* found a single font using this format, however.
*
-   *   FT_PIXEL_MODE_GRAY16 ::
-   * A 16-bit per pixel bitmap used to represent signed distances in a
-   * signed distance field bitmap as needed by @FT_RENDER_MODE_SDF.
-   * Values are represented in a 6.10 fixed-point format; this means
-   * that you have to divide by 1024 to get the actual data generated by
-   * the SDF rasterizers.
-   *
*   FT_PIXEL_MODE_LCD ::
* An 8-bit bitmap, representing RGB or BGR decimated glyph images used
* for display on LCD displays; the bitmap is three times wider than
@@ -194,7 +187,6 @@ FT_BEGIN_HEADER

Re: new release?

[Anuj Verma]

Hello Alexei,



*> Using signed char is a bit problematic because the FT_Bitmap buffer is >
unsigned char. Going from signed to unsigned is well-defined, but >
backwards is implementation-defined.*

I'm assuming here that `FT_Bitmap` is simply a typeless buffer and the
client
can do a pointer cast ( like: FT_Char* buff = (FT_Char*)buffer ) to get the
values
without modifying/casting each and every value.






*> Can we simply map distances like this? > > SDF = 128 * ( distance -
spread ) / spread; > > assuming positive values outside and clamping to
[0,255] *

Mapping the buffer to any range is fine as long as the client can figure
out where
the actual edge is. In the current implementation the edge is at `0`.  So
if we map
the [-128, 127] range to [0, 255], the values from [0, 127] will be
`inside` and
values [129, 255] will be `outside` with the edge being at 128.

Thanks,
Anuj

Re: new release?

[Anuj Verma]

Hello Alexei, Werner,


*> Since you and Alexei agree on 8bit being enough: Please change to >
8bit!*

I have made the relevant changes in both freetype and freetype-demos.
Please check the patches below. I have trimmed the 16bit 6.10 value to
normalized 8 bit values.

As for freetype-demos, I need to change a major part of it since most of it
is just hacks. I'm already rewriting the demo, it's going a bit slow due to
other
stuff I have in my hands right now. I'll send it as soon as I can.

Also, the demo programs are not compiling due to missing `gdiplus`
dependency.
Please add it as well:

---

diff --git a/graph/win32/rules.mk b/graph/win32/rules.mk
index 2dd0f14..6287345 100644
--- a/graph/win32/rules.mk
+++ b/graph/win32/rules.mk
@@ -28,19 +28,19 @@ ifeq ($(PLATFORM),windows)
   # now update COMPILE_GRAPH_LIB according to the compiler used on Win32
   #
   ifeq ($(firstword $(CC)),gcc)   # test for GCC
-GRAPH_LINK += -luser32 -lgdi32
+GRAPH_LINK += -luser32 -lgdi32 -lgdiplus
   endif

   ifeq ($(findstring $(CC),cl icl), $(CC))# test for Visual C++ &
Intel C++
 COMPILE_GRAPH_LIB = lib /nologo /out:$(subst
/,$(COMPILER_SEP),$(GRAPH_LIB) $(GRAPH_OBJS))
 LINK  = cl /nologo /MD /Fe$(subst /,$(COMPILER_SEP),$@ $<
$(FTLIB))
-GRAPH_LINK   += user32.lib gdi32.lib
+GRAPH_LINK   += user32.lib gdi32.lib gdiplus.lib
   endif

   ifeq ($(CC),lcc)   # test for LCC-Win32
 COMPILE_GRAPH_LIB = lcclib /out:$(subst /,$(COMPILER_SEP),$(GRAPH_LIB)
$(GRAPH_OBJS))
 LINK  = lcclnk -o $(subst /,$(COMPILER_SEP),$@ $< $(FTLIB))
-GRAPH_LINK   += user32.lib gdi32.lib
+GRAPH_LINK   += user32.lib gdi32.lib gdiplus.lib
   endif

   ifeq ($(CC),bcc32) # test for Borland C++

Thanks,
Anuj
commit 623e66a142252b15ddfbd8f1c73874eae44a8f70
Author: Anuj Verma 
Date:   Fri May 21 19:41:58 2021 +0530

[ftsdf] Synchronize with the change made in the `sdf` renderer.

* src/ftsdf.c (draw): Change logic to utilize 8bit SDF instead of 16.

diff --git a/src/ftsdf.c b/src/ftsdf.c
index a638c3e..796b737 100644
--- a/src/ftsdf.c
+++ b/src/ftsdf.c
@@ -436,7 +436,7 @@
 Box  sample_region;
 
 Vec2   center;
-FT_Short*  buffer;
+FT_Char*   buffer;
 
 
 if ( !bitmap || !bitmap->buffer )
@@ -496,7 +496,7 @@
   draw_region.xMax= display->bitmap->width;
 }
 
-buffer = (FT_Short*)bitmap->buffer;
+buffer = (FT_Char*)bitmap->buffer;
 
 /* Finally loop over all pixels inside the draw region*/
 /* and copy pixels from the sample region to the draw region. */
@@ -516,12 +516,12 @@
 {
   FT_UInt   bitmap_index = ( y / status.scale ) * bitmap->width +
  x / status.scale;
-  FT_Short  pixel_value  = buffer[bitmap_index];
+  FT_Char   pixel_value  = buffer[bitmap_index];
 
 
   /* If nearest filtering then simply take the value of the */
   /* nearest sampling pixel.*/
-  min_dist = (float)pixel_value / 1024.0f;
+  min_dist = (float)pixel_value / 128.0f;
 }
 else
 {
@@ -560,22 +560,22 @@
   indc[2] = (int)bi_y * width + (int)bi_x + 1;
   indc[3] = ( (int)bi_y + 1 ) * width + (int)bi_x + 1;
 
-  dist[0] = (float)buffer[indc[0]] / 1024.0f;
+  dist[0] = (float)buffer[indc[0]] / 128.0f;
 
   if ( indc[1] >= width * rows )
 dist[1] = -status.spread;
   else
-dist[1] = (float)buffer[indc[1]] / 1024.0f;
+dist[1] = (float)buffer[indc[1]] / 128.0f;
 
   if ( indc[2] >= width * rows )
 dist[2] = -status.spread;
   else
-dist[2] = (float)buffer[indc[2]] / 1024.0f;
+dist[2] = (float)buffer[indc[2]] / 128.0f;
 
   if ( indc[3] >= width * rows )
 dist[3] = -status.spread;
   else
-dist[3] = (float)buffer[indc[3]] / 1024.0f;
+dist[3] = (float)buffer[indc[3]] / 128.0f;
 
   m1 = dist[0] * ( 1.0f - nbi_y ) + dist[1] * nbi_y;
   m2 = dist[2] * ( 1.0f - nbi_y ) + dist[3] * nbi_y;
@@ -615,7 +615,6 @@
 
   /* normalize using `status.spread` */
   final_dist  = final_dist < 0 ? -final_dist : final_dist;
-  final_dist /= (float)status.spread;
 
   /* invert the values */
   final_dist  = 1.0f - final_dist;
@@ -686,12 +685,16 @@
   goto Exit;
 }
 
-#ifdef __linux__
+
 int  flip_y = 1;
 
+#ifdef __linux__
+flip_y = 0;
+#endif
+
 FT_CALL( FT_Property_Set( handle->library, "sdf", "flip_y", _y ) );
 FT_CALL( FT_Property_Set( handle->library, "bsdf", "flip_y", _y ) );
-#endif
+
 
 grSetTitle( display->surface, "Signed Distance Field Viewer" );
 event_color_change();
commit 2b99e72ca36cf25e8df0d9341e1cd094987b4

Re: new release?

[Anuj Verma]

Hello Werner, Alexei,

Apologies for not replying earlier.

We have already discussed 8 Bit SDF earlier and I agree that 8 Bits is
enough for producing acceptable interpolation for rendering. Here is the
mail for your reference:
https://lists.nongnu.org/archive/html/freetype-devel/2020-12/msg00042.html

Back then I was waiting for others opinion and did not add this to the
renderers
however, if everyone agrees now I'll prepare a patch to remove 16 Bit
support and
only allow 8 Bit SDF. It will conserve memory and also eliminate the
endiness issue
that you mentioned earlier.

Thanks,
Anuj

Re: SDF format

[Anuj Verma]

 *> Isn't the renderer implementing a multi-channel SDF scheme?*
*> I thought I saw multi-channel mentioned in a commit message.*

*> I stumbled upon multi-channel at  https://github.com/Chlumsky/msdfgen
*
*> where the readme seems to imply simple 8-bit single-channel SDFs aren't
satisfactory.*

No, the rendering implementation is a single-channel SDF. Multi-channel SDF
is a future improvement which I will add after polishing the current
implementation.
When compared to multi-channel, single-channel SDF isn't satisfactory.
However, even
'msdfgen' outputs 8-bit SDF (both single and multi channel) and they render
without
any issues.

Anuj

Re: SDF module now in master

[Anuj Verma]

*> FT_PIXEL_MODE_GRAY16 is endian-sensitive and the description implies >
that we go by short int divided by 1024 in whatever endianness. Do we*
* > need to say that?*

I can't quite understand how the format is endian-sensitive ? If it
necessary to add this to the description please do so.

Anuj

Re: SDF format

[Anuj Verma]

Hello Alexei,

*> [...] I went searching for *practical* examples on the internet and*
*> found very few.*

There are quite a few examples on youtube, and most of them use 8-bit
buffers to represent SDF.




*> This blog post>
https://blog.mapbox.com/drawing-text-with-signed-distance-fields-in-mapbox-gl-b0933af6f817

> and some others refer to OpenGL textures as the next step, Their > format
is unclear to me but it seems that we should align.*

I don't think we have to align the format with OpenGL. We can convert
the SDF data to any format in OpenGL, so I don't think we need to align.
In the blog you mentioned the OpenGL texture format is probably GRAY8.

*> The blog post that I mentioned is okay with GRAY8 unevenly split at 192,*

*> which brings the question of units too. The units or scale of SDF do not
> seem to be important. *

For most cases negative values are simply ignored, therefore uneven
splitting
is okay. But, that might not be the case in every scenario. The units are
not
important, as long we can create acceptable interpolation to render text.

* > Finally, I am not sure if you realize that FreeType gray coverage*

*> [...] I wonder if we really need 16 bits for acceptable > interpolation.
Probably not.*

I do know about the FreeType's antialiased rendering, the 'bsdf' renderer
takes advantage of the coverage values to generate SDF.

As for the number of bits, even behdad told me that 8 bits is enough to
produce respectable rendering:
https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00118.html
And even some other SDF generators use 8 bits to represent the final SDF
output data :
 - https://github.com/libgdx/libgdx/wiki/Distance-field-fonts
 - https://github.com/rougier/freetype-gl/blob/master/distance-field.c
I did test 8 bit SDF today, and the final rendering output is
similar to 16 bit. For my testing I used 3.5 fixed point representation,
similar to what is used in skia. (
https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg9.html)

Finally, we can definitely use 8 bit output to represent SDF and render
acceptable text using it. Now, we can either eliminate the current 16 bit
output, or, we can keep both 16 and 8 bit output. What do you think will be
the better option ? I think we should keep a single output (probably 8 bit)
and later add an option to directly output floating point data (if we decide
to add floating point calculations to FreeType)

Anuj

Re: sdf: revise memory allocation debugging

[Anuj Verma]

 > [...]
>
> What do you think?  If you agree, could you prepare a patch?

I totally agree. The memory dump is enough to check the usage.
I have attached a patch that strip all the custom memory tracking
stuff.

Anuj
diff --git a/ChangeLog b/ChangeLog
index 0ab12ff54..140b8f11e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2020-12-26  Anuj Verma  
+
+[sdf] Remove custom memory tracker.
+
+   * src/sdf/ftsdf.c: Replaced `SDF_ALLOC' and `SDF_FREE'
+   with `FT_ALLOC' and `FT_FREE' respectively. Also, removed
+   the custom memory tracking functions ( `sdf_alloc', `sdf_free' )
+   and macros ( `SDF_MEMORY_TRACKER_*' ). The internal FreeType
+   memory tracker is enough.
+   
 2020-12-24  Werner Lemberg  
 
[sdf] Fix `make multi`.
diff --git a/src/sdf/ftsdf.c b/src/sdf/ftsdf.c
index 175d372f4..3aa21e92a 100644
--- a/src/sdf/ftsdf.c
+++ b/src/sdf/ftsdf.c
@@ -89,10 +89,10 @@
* }
* ```
*
-   * (4) After running this algorithm the bitmap contain sinformation about 
the closest
-   * point from each point to the outline of the shape.  Of course,
-   * while this is the most straightforward way of generating SDF, we
-   * use various optimizations in this rasterizer.  See the
+   * (4) After running this algorithm the bitmap contains information about
+   * the shortest distance from each point to the outline of the shape.  
+   * Of course, this is the most straightforward way of generating
+   * SDF, we use various optimizations in this rasterizer.  See the
* `sdf_generate_*' functions in this file for all details.
*
* The optimization currently used by default is subdivision; see
@@ -114,123 +114,6 @@
 #define FT_COMPONENT  sdf
 
 
-  /**
-   *
-   * for tracking used memory
-   *
-   */
-
-  /* The memory tracker only works when `FT_DEBUG_MEMORY` is defined; */
-  /* we need some variables such as `_ft_debug_file`, which aren't*/
-  /* available otherwise. */
-#if defined( FT_DEBUG_LEVEL_TRACE ) && defined( FT_DEBUG_MEMORY )
-
-
-#undef FT_DEBUG_INNER
-#undef FT_ASSIGNP_INNER
-
-#define FT_DEBUG_INNER( exp )  ( _ft_debug_file   = __FILE__, \
- _ft_debug_lineno = line, \
- (exp) )
-#define FT_ASSIGNP_INNER( p, exp )  ( _ft_debug_file   = __FILE__, \
-  _ft_debug_lineno = line, \
-  FT_ASSIGNP( p, exp ) )
-
-
-  /* To be used with `FT_Memory::user' in order to track */
-  /* memory allocations. */
-  typedef struct  SDF_MemoryUser_
-  {
-void*prev_user;
-FT_Long  total_usage;
-
-  } SDF_MemoryUser;
-
-
-  /*
-   * These functions are used while allocating and deallocating memory.
-   * They restore the previous user pointer before calling the allocation
-   * functions.
-   */
-
-  static FT_Pointer
-  sdf_alloc( FT_Memory  memory,
- FT_Longsize,
- FT_Error*  err,
- FT_Int line )
-  {
-SDF_MemoryUser*  current_user;
-FT_Pointer   ptr;
-FT_Error error;
-
-
-current_user = (SDF_MemoryUser*)memory->user;
-memory->user = current_user->prev_user;
-
-if ( !FT_QALLOC( ptr, size ) )
-  current_user->total_usage += size;
-
-memory->user = (void*)current_user;
-*err = error;
-
-return ptr;
-  }
-
-
-  static void
-  sdf_free( FT_Memorymemory,
- FT_Pointer  ptr,
- FT_Int  line )
-  {
-SDF_MemoryUser*  current_user;
-
-
-current_user = (SDF_MemoryUser*)memory->user;
-memory->user = current_user->prev_user;
-
-FT_FREE( ptr );
-
-memory->user = (void*)current_user;
-  }
-
-
-#define SDF_ALLOC( ptr, size )   \
-  ( ptr = sdf_alloc( memory, size,   \
- , __LINE__ ), \
-error != 0 )
-
-#define SDF_FREE( ptr ) \
-  sdf_free( memory, ptr, __LINE__ )
-
-#define SDF_MEMORY_TRACKER_DECLARE()  SDF_MemoryUser  sdf_memory_user
-
-#define SDF_MEMORY_TRACKER_SETUP()   \
-  sdf_memory_user.prev_user   = memory->user;\
-  sdf_memory_user.total_usage = 0;   \
-  memory->user= _memory_user
-
-#define SDF_MEMORY_TRACKER_DONE()\
-  memory->user = sdf_memory_user.prev_user;  \
- \
-  FT_TRACE0(( "[sdf] sdf_raster_render:" \
-  " Total memory used = %ld\n",  \
-  sdf_memory_user.total_usage ))
-
-
-#else /* !FT_DEBUG_LEVEL_TRACE */
-
-
-#define SDF_ALLOC  FT_QALLOC
-#define SDF_FREE   FT_FREE
-
-#define SDF_M

Re: SDF module ready for integration

[Anuj Verma]

 > That would be nice too. Can you avoid direct access altogether and use
> grBlitGlyphToBitmap, which works with 256-level gray and lcd bitmaps.
> So you would need to scale dimensions and bits accordingly.

Yeah, while rewriting the demo program I will use the API calls instead of
handling the display buffer manually.

> In other words, why not use ftgrid?

Using 'ftgrid' for 'sdf' will require too many additions to handle the
rendering +
another usage screen since 'ftsdf' uses many keys to tweak the values. But
I will see if it's possible to use 'ftgrid'.

Anuj

Re: SDF module ready for integration

[Anuj Verma]

 > Hmmm. bV5CSType lists LCS_sRGB. I would rather switch to
> BITMAPV5HEADER. Does that work for you?

That should work, however, 'LCS_sRGB' is not defined in the 'wingdi.h'
header file that comes with mingw ( as of the latest version ). Only
'LCS_CALIBRATED_RGB' is defined.

Re: SDF module ready for integration

[Anuj Verma]

 > Anuj, can you change the `COPY` line in file `windows/detect.mk`
> accordingly and check whether it works?

Yes, it does work.

  ifeq ($(OS),Windows_NT)
COPY := >nul cmd.exe /c copy
  else
COPY := >nul copy
  endif  # test NT

Re: SDF module ready for integration

[Anuj Verma]

> Please replace
>
> $(shell $(COPY) \
>   $(subst /,$(SEP),submodules/dlg/include/dlg/dlg.h src/dlg/dlg))
> $(shell $(COPY) \
>   $(subst /,$(SEP),submodules/dlg/include/dlg/output.h src/dlg/dlg))
> $(shell $(COPY) \
>   $(subst /,$(SEP),submodules/dlg/src/dlg/dlg.c src/dlg))
>
> with
>
> $(shell $(COPY) $(subst /,$(SEP),submodules/dlg/include/dlg/dlg.h
src/dlg/dlg))
> $(shell $(COPY) $(subst /,$(SEP),submodules/dlg/include/dlg/output.h
src/dlg/dlg))
> $(shell $(COPY) $(subst /,$(SEP),submodules/dlg/src/dlg/dlg.c
src/dlg))
>
> Does this work?

No, that does not work. The issue is probably with the 'shell' command. It
paste the output
of the 'copy' command on the same line as the 'shell' command ( or it
replaces the line with
the $(shell) to the output of 'copy' command ), which is something like:

1 file(s) copied.

Assigning the output of the 'shell' command to the temporary variable fixes
the error.

_temp := $(shell $(COPY) \
  $(subst /,$(SEP),submodules/dlg/include/dlg/dlg.h src/dlg/dlg))
_temp := $(shell $(COPY) \
  $(subst /,$(SEP),submodules/dlg/include/dlg/output.h src/dlg/dlg))
_temp := $(shell $(COPY) \
  $(subst /,$(SEP),submodules/dlg/src/dlg/dlg.c src/dlg))

Re: SDF module ready for integration

[Anuj Verma]

> OK.  Anuj, do you time to work on this?

My last exam is on the 25th, after that I can start rewriting the demo
program.

>> Right now it writes directly to the buffer assuming 24-bit (rgb888).
>> So the quick fix for now is "800x600x24" on line 612.
>
> Thanks, it works!  I have updated my local 'sdf' branch.[*]

You can also use the patch I sent. It calculates the number of bits
per pixel before writing to the display buffer. That way it can even
work with 32-bit buffer.

Thanks,
Anuj

Re: SDF module ready for integration

[Anuj Verma]

 Hello Werner, Alexie,

> I've polished your SDF driver; see the 'sdf' branches in both the
> 'freetype2' and 'freetype2-demos' repositories.  Basically, it's ready
> to be merged with 'master' :-)

Thanks for polishing the modules, they look great now. I'm happy that
the driver will finally be merged with 'master' :-)

> Note, however, that there is a problem with the graphics display: On
> Linux, something has changed in the graphics driver of the demos –
> instead of a single image I get four, with stripes (see attached
> image).

The issue is on windows as well. It is a mistake from my end, when I
wrote the demo program I assumed that the surface bitmap is 24 bits
per pixel, but it is 32 bits per pixel now. I have attached a patch below
( sdf_fix.txt ) to fix the problem, if you'd like, I can apply it to the
`sdf' branch.

There are a couple more issues on windows:

Firstly, Building the library on windows with gnu make give me the
following error:
---
Copying files from `submodules/dlg' to `src/dlg'
A subdirectory or file src\dlg\dlg already exists.
builds/toplevel.mk:127: *** missing separator.  Stop.
---
I tried using two versions of gnu make ( i.e. 3.81 and 4.3 ), and both
give me the exact same error. I don't have much idea about the error, but
it only occurs with the '$(COPY)' command ( 'mkdir' and 'del' works fine ).
Please do check it out. It might as well be the case with my system, so
I will let you know if I figure something out.

Lastly, in the demos program, the symbol 'LCS_sRGB' is not defined, due
to which the build fails on windows. The MSDN page only list one value for
the field 'bV4CSType' and that is 'LCS_CALIBRATED_RGB', so changing the
value on line 267 fixes the error. I have attached a patch for this too. (
fix_build_windows.txt )

> In the long run, ftsdf needs to become more agnostic to the display
> mode. Right now it writes directly to the buffer assuming 24-bit
> (rgb888).

Right! I initially just wrote the program quickly to view the output of the
renderers, I hardcoded a few things which can cause issues in the future.
I will rewrite the entire program once I get some time from my college.

If there is anything else please do let me know.

Thanks and Regards,
Anuj
diff --git a/graph/win32/grwin32.c b/graph/win32/grwin32.c
index 85a6ebe..9dfcf1e 100644
--- a/graph/win32/grwin32.c
+++ b/graph/win32/grwin32.c
@@ -264,7 +264,7 @@ gr_win32_surface_set_icon( grWin32Surface*  surface,
   BITMAPV4HEADER  hdr = { sizeof( BITMAPV4HEADER ),
   0, 0, 1, 32, BI_BITFIELDS, 0, 0, 0, 0, 0,
   0x00FF, 0xFF00, 0x00FF, 0xFF00,
-  LCS_sRGB };
+  LCS_CALIBRATED_RGB };
 
 
   if ( !icon )
diff --git a/ChangeLog b/ChangeLog
index 73db727..fcfebf1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2020-12-23  Anuj Verma  
+
+   [ftsdf] Fix glyph rendering issue.
+
+   * src/ftsdf.c (draw): Compute the number of
+   bits per pixel, rather than assuming 24 bits
+   per pixel.
+
 2020-08-24  Anuj Verma  
 
[ftsdf] Add better usage section.
diff --git a/src/ftsdf.c b/src/ftsdf.c
index 8d7ef88..568da89 100644
--- a/src/ftsdf.c
+++ b/src/ftsdf.c
@@ -437,11 +437,16 @@
 
 Vec2   center;
 FT_Short*  buffer;
-
+FT_Int bytes_per_pixel;
 
 if ( !bitmap || !bitmap->buffer )
   return FT_Err_Invalid_Argument;
 
+/* compute the number of bytes per pixel of the window surface */
+bytes_per_pixel = display->bitmap->pitch / display->bitmap->width;
+bytes_per_pixel = bytes_per_pixel < 0 ?
+ -bytes_per_pixel : bytes_per_pixel;
+
 /* compute center of display */
 center.x = display->bitmap->width / 2;
 center.y = display->bitmap->rows  / 2;
@@ -600,10 +605,11 @@
   alpha *= 255;
 
   /* finally copy the target value to the display buffer */
-  display_index *= 3;
-  display->bitmap->buffer[display_index + 0] = (unsigned char)alpha;
-  display->bitmap->buffer[display_index + 1] = (unsigned char)alpha;
-  display->bitmap->buffer[display_index + 2] = (unsigned char)alpha;
+  display_index *= bytes_per_pixel;
+  for ( FT_Int pixel = 0; pixel < bytes_per_pixel; pixel++ ) {
+display->bitmap->buffer[display_index + pixel] =
+  (unsigned char)alpha;
+  }
 }
 else
 {
@@ -622,10 +628,11 @@
   final_dist *= 255;
 
   /* finally copy the target value to the display buffer */
-  display_index *= 3;
-  display->bitmap->buffer[display_index + 0] = (unsigned 
char)final_dist;
-  display->bitmap->buffer[display_index + 1] = (unsigned 
char)final_dist;
-  display->bitmap->buffer[display_index + 2] = (unsigned 
char)final_dist;
+

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

[Anuj Verma]

Hello Behdad,

> Thank you Anuj. I really enjoyed observing your work this summer, even
though I didn't get to contribute more review.

Thank you for checking it out and for your suggestions.

>> Lemma: if the closest point on curve [0,1] is to the endpoint at t=1 and
the cubic equation has no real root at t=1, the cubic equation must have at
least one real root at some t > 1.
>> Similarly, if the closest point on curve [0,1] is to the endpoint at t=0
and the cubic equation has no real root at t=0, the cubic equation must
have at least one real root at some t < 0.
>>
>> As such, you just need to compute all real roots, clamp them to [0,1]
and remove duplicates.
>
> Here's the proof for the first case: Consider the derivative of the
distance, called "the function" from here on. It's a continuous function.
At t=1 the function is a negative number because of the assumptions.
> When t tends towards +infinity, the function approaches +infinity. As
such, there exist t > 1 where the function is zero.

Thanks for proof. I finally understand what is happening in the code that I
have written and can update the comments.

Best,
Anuj

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

[Anuj Verma]

 >> You can check it out here:
>> https://gitlab.com/-/snippets/2007070
>
> Thank you for this project! This is unbelievable amount of work for
> just one summer. Please stay in touch and good luck in your future
> adventures!

Thank you Alexei!
I will stay in touch. There are still many things left to add in the
renderers
which I intend to do next.

Thank you all for your time during the summer,
Anuj

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

[Anuj Verma]

 >> I have written the final report for my project.
>>
>> You can check it out here:
>> https://gitlab.com/-/snippets/2007070
>
> Looks great, thanks!

Thanks for checking it out!

Anuj

[ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

[Anuj Verma]

Hello All,

I have written the final report for my project.

You can check it out here:
https://gitlab.com/-/snippets/2007070

I'm also attaching a copy if in case the link goes down.

Thanks,
Anuj


anuj_report.md
Description: Binary data

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 >> Werner, Are you still interested in adding API to remove overlaps?
>
> Yes, I am.

Alright, I will start reading more about it after GSoC.

>> I have updated the demo to include the new algorithm to handle
>> overlaps.  [...]
>
> Thanks, too.  What do you think about integrating this into (at least)
> `ftview`?

Yes, it can be integrated into the existing demo programs, however I
think it should have a separate demo program because of the way
SDF is rendered, it has a raw and reconstruction view as well as
various properties and bilinear filtering. Because of that I think
integrating it completely into the existing programs will clutter the
programs.
On the other hand It makes sense to integrate them into the
existing programs, so that we can compare them with other
renderers and see how it looks. It will require significant changes
to the graphics subsytem (adding bilinear filtering, render 16 bpp,
the reconstruction mode etc.). So, perhaps I should do it after GSoC?

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei, Werner,

>> I meant it all along but perhaps it is hard to do it on the fly. Ther
>> rules seem to be as follows:
>>
>> 1) Both outside (both positive), choose a smaller value
>> 2) Both inside (both negative), choose a smaller value as in (-5 < -4)
>> not by absolute value
>> 3) one inside one outside, choose a smaller value as in (-3 < 2) not
>> by absolute value
>>
>> I.e. always choose a smaller value combining two contours so it seems
>
> Along with this we probably also need to find the resultant vector in case
> two distances are non infinite at a same point (i.e. the distance values
are
> less than spread), that we can find the distance to the corner even tho
> there is no actual corner in some glyphs.

I've added the overlapping support according to your algorithm, however I
have
modified the rule as follows:

-> Generate SDF for each contour in a separate bitmap.
-> for combining all the SDF to one use the below rule:
  -> for each pixel/grid point:
   c = for all clockwise contours find the largest signed value.
ac = for all counter-clockwise contours find the smallest
signed value.
   final_value = smallest signed value of `c' and `ac'.

It works well for all of the glyphs that I checked apart from glyphs with
self
intersecting contours, because they can't be separated into different
bitmaps. To
handle self intersecting contours I think there is only one way and that is
to remove
the overlaps.

[
Werner,
  Are you still interested in adding API to remove overlaps? I watched the
skia code
  and the video on how it's done in skia. I think it's doable, the only
tricky part that I
  think is to find the intersecting point of contours, because they use a
4th degree
  polynomial to find the intersections.
  If you're still interested in adding the API, I can start reading more
about it after GSoC
  and then add it.
]

I have updated the demo to include the new algorithm to handle overlaps. I
have also
disabled all the optimization modes except the subdivision optimization (it
will be the
default one from now on until I find something even faster). Here is the
link:
https://github.com/preversewharf45/ft2sdf-demo, for help screen press '?'
or F1. There is
a `CascadiaCode.ttf' font which is full of overlaps, so that you can check
how the new
algorithm performs.

And now that GSoC is almost over, I will fix the compiler warnings first.
And then I will
write a brief description of how both `sdf' and `bsdf' renderers work in
the source files.
And finally I will create a new branch and add the code there. If there is
anything else
please do let me know.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > I meant it all along but perhaps it is hard to do it on the fly. Ther
> rules seem to be as follows:
>
> 1) Both outside (both positive), choose a smaller value
> 2) Both inside (both negative), choose a smaller value as in (-5 < -4)
> not by absolute value
> 3) one inside one outside, choose a smaller value as in (-3 < 2) not
> by absolute value
>
> I.e. always choose a smaller value combining two contours so it seems

Along with this we probably also need to find the resultant vector in case
two distances are non infinite at a same point (i.e. the distance values are
less than spread), that we can find the distance to the corner even tho
there is no actual corner in some glyphs.

Also, my progress has been slow lately because my classes have started
and there is the campus placement thing going on. I haven't yet started
doing the overlapping support, I will try to add it by next next week and
see if it works.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > Yeah. We should basically think of overlaying or combining two
> distance fields, generated independently one for each contour.
> Has this been discussed in the literature?

No, it has not been. That sounds interesting, thanks for the idea.
I will think about it tomorrow, perhaps it might solve the issue. My
only concern would be the additional memory usage, because some
glyphs have many contours. But yeah we can turn it ON only for
overlapping contours.

Thanks for the idea,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> Can you describe discontinuities with the same sign if I overlook them?

So, I found there are two types of discontinuities due to overlapping
contours:

A) Discontinuity in sign. (i.e. there is a sudden jump from negative to
positive)
B) Discontinuity in distances. (i.e. the points that should be at
infinity/spread have smaller distances)

Here is an example of a SDF generated from glyph with overlaps:
https://i.imgur.com/3pqHZWd.png
In that image the right side is correct (generated from bitmap), and the
left side has both A and B
types of  discontinuities.

What you are saying about detecting sudden jump from large negative to large
positive can work for discontinuities in sign. I tried that and here is an
example: https://i.imgur.com/unRB23Z.png
(ignore the weird lines in the image, that can be fixed). But even after
fixing the
sign there are pixels inside the outline which have shortest distance to
the curves
inside the outline. (basically the pixels around the overlap points to the
overlapping
curve, which causes discontinuous distances). Moreover they interpolate
smoothly
so there is no way to find the actual distance which will be to some curve
at the border
of the outline instead of inside the outline.

Also, I looked at a library (msdfgen) which handles overlapping contours
without
removing the overlaps. It works well, but it doesn't work for
self-intersecting contours,
that is why I'm not sure whether it's worth implementing.

Finally, I can find and fix signs such that all points inside a shape are
positive and
all points outside are negative. But I don't know how I can fix the
incorrect distances
caused by the overlaps. Here is one final example:
https://i.imgur.com/jiaqiBS.png
In this the point `P' has a positive sign and it points to a line inside
the shape, which
is not correct, instead it should point to the corner. Moreover there is no
corner in the
shape because they are two separate contours, so I think removing the
overlaps is
the best way to handle this.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

> Only FT_PIXEL_MODE_MONO is necessary to add. I do not understand how
> LCD or BGRA can be used for SDF; GRAY2 and GRAY4 are defunct.

It might be possible to convert LCD and BGRA to SDF, either using  a single
channel or by converting them to grayscale, but yeah I don't think that
will be
useful. And I will skip GRAY2 and GRAY4.

> If I understand correctly, overlaps cause unexpected discontinuity in
> SDF, which otherwise should not have any. I doubt that detecting and
> removing contour overlaps is productive. I would rather deal with the
> discontinuity directly. Perhaps there is a clever way to ignore
> smaller distances that unexpectedly have an opposite sign. The
> distance cannot change by more than the grid size. If it does, ignore
> the offending value.

Yes, overlaps cause discontinuity in both sign and distances. Detecting
unexpected opposite sign is possible, but the sign may not be opposite.
In many cases the sign is not flipped (there is no unexpected change
in sign) and the distances interpolate smoothly, in those cases it becomes
hard to find the true distances of the point.
There is a way to do it, which is done in the 'msdfgen' library, but it is
not perfect and I don't know whether it will work with subdivision
optimization
or not.
I will try to think of some other way of handling overlaps without actually
removing overlaps, but I think the most robust way to do it would be to
remove the overlaps.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Werner, Alexei,

I have mostly completed the bitmap to SDF renderer (bsdf), there
are only a few things remaining such as support for all pixel
modes (currently it only work with FT_PIXEL_MODE_GRAY),
and warnings etc. I did say before that the bitmap to SDF will require
less memory than the other, but that is not the case, after I read the
algorithm and implemented it, both the renderers have similar memory
requirements. The only advantage of the  bsdf renderer is that it can
handle glyphs with overlaps.

Next, I will be finishing the bsdf renderer and then writing the
documentation
for all the functions (should I write for structs as well? i.e. detailed
description
of all the members). Also is there any other kind of documentation that I
should
add ?
After that I have not decided what to do. I have a few things in mind
(adding
floating point support, removing overlaps and a few more). But we can
discuss
that once I have finished the documentation. (Also, I will keep improving
the
existing algorithms, optimizing and removing any bug that I find along the
way)

I have updated the demo (https://github.com/preversewharf45/ft2sdf-demo)
and this time I have added the help screen ('?' or F1), I have also included
a font `CascadiaCode.ttf' which is full of overlaps, so that you can compare
both the renderers.

Thanks,
Anuj

Re: [ft2-demos][win32] Compiler Warnings

[Anuj Verma]

Hello Alexei,

> After I regenerated ftconfig.h with ./autogen.sh the warnings went
> away for me. Do you still see it after ./autogen.sh?

That doesn't seem to work on windows.

The warning is because of the ` FT_INTERNAL_FUNCTION_ATTRIBUTE'
macro which is defined to __attribute__((visibility("hidden")). So defining
it to nothing fixes all the warnings.

```
diff --git a/include/freetype/internal/compiler-macros.h
b/include/freetype/internal/compiler-macros.h
index b62c0777b..981a0ffaf 100644
--- a/include/freetype/internal/compiler-macros.h
+++ b/include/freetype/internal/compiler-macros.h
@@ -94,7 +94,9 @@ FT_BEGIN_HEADER
  * and faster code on ELF-based platforms. Place this before a function
  * declaration.
  */
-#if (defined(__GNUC__) && __GNUC__ >= 4) || defined(__clang__)
+#if defined(_WIN32)
+#define FT_INTERNAL_FUNCTION_ATTRIBUTE  /* nothing */
+#elif (defined(__GNUC__) && __GNUC__ >= 4) || defined(__clang__)
 #define FT_INTERNAL_FUNCTION_ATTRIBUTE
 __attribute__((visibility("hidden")))
 #else
 #define FT_INTERNAL_FUNCTION_ATTRIBUTE  /* nothing */
```

Anuj

Re: [ft2-demos][win32] Compiler Warnings

[Anuj Verma]

I don't think it has anything to do with the demos.
The warnings are there while building freetype2.
As you said, I think some recent changes in the
config file is causing this, it's not there in my own
branch.

Anuj

On Sun, Jul 26, 2020, 8:03 PM Alexei Podtelezhnikov 
wrote:

> Don’t -DFT_EXPORT just yet. Is this because the demos are “illegally”
> built with FT2_BUILD_LIBRARY?
>
> Alexei
>
> On Jul 26, 2020, at 08:02, Anuj Verma  wrote:
>
> > for a static lib, FT_EXPORT should be set to nothing. @Anuj Verma add
> > -DFT_EXPORT to CPPFLAGS at configure time
>
> Alright. It wasn't there previously tho.
>
> Anuj
>
>

Re: [ft2-demos][win32] Compiler Warnings

[Anuj Verma]

 > for a static lib, FT_EXPORT should be set to nothing. @Anuj Verma add
> -DFT_EXPORT to CPPFLAGS at configure time

Alright. It wasn't there previously tho.

Anuj

Re: [ft2-demos][win32] Compiler Warnings

[Anuj Verma]

 > it is related to FT_EXPORT in ftconfig.h

I see. Thanks!

> are you compiling static library of freetype ? If you compile a shared
> library, you should not have this warning

Yes, I am compiling a static library. And yes, they disappear when I compile
a dynamic library.
But I think they shouldn't be there even while building a static library.
Because
`FT_EXPORT' is used at many places there are many warnings (I have attached
the output).

Anuj
gcc -ansi -pedantic -I./objs -I./builds/windows -I./include  -c -g -O3 -Wall 
-DFT2_BUILD_LIBRARY -o objs/ftsystem.o src/base/ftsystem.c
src/base/ftsystem.c: In function 'FT_Stream_Open':
src/base/ftsystem.c:282:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
src/base/ftsystem.c: In function 'FT_New_Memory':
src/base/ftsystem.c:318:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
src/base/ftsystem.c: In function 'FT_Done_Memory':
src/base/ftsystem.c:330:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
gcc -ansi -pedantic -I./objs -I./builds/windows -I./include  -c -g -O3 -Wall 
-DFT2_BUILD_LIBRARY -o objs/ftdebug.o src/base/ftdebug.c
src/base/ftdebug.c: In function 'ft_debug_init':
src/base/ftdebug.c:277:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   ft_debug_init( void )
   ^
src/base/ftdebug.c: In function 'FT_Trace_Get_Count':
src/base/ftdebug.c:287:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
src/base/ftdebug.c: In function 'FT_Trace_Get_Name':
src/base/ftdebug.c:296:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
src/base/ftdebug.c: In function 'FT_Trace_Disable':
src/base/ftdebug.c:303:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
src/base/ftdebug.c: In function 'FT_Trace_Enable':
src/base/ftdebug.c:309:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   FT_Trace_Enable( void )
   ^~~
gcc -ansi -pedantic -I./objs -I./builds/windows -I./include  -c -g -O3 -Wall 
-DFT2_BUILD_LIBRARY -o objs/ftinit.o src/base/ftinit.c
gcc -ansi -pedantic -I./src/base -I./objs -I./builds/windows -I./include  -c -g 
-O3 -Wall -DFT2_BUILD_LIBRARY -o objs/ftbase.o ./src/base/ftbase.c
In file included from ./src/base/ftbase.c:22:
./src/base/ftcalc.c: In function 'FT_Hypot':
./src/base/ftcalc.c:164:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'FT_MulDiv_No_Round':
./src/base/ftcalc.c:502:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'FT_Matrix_Multiply_Scaled':
./src/base/ftcalc.c:744:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'FT_Matrix_Check':
./src/base/ftcalc.c:814:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'FT_Vector_Transform_Scaled':
./src/base/ftcalc.c:839:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'FT_Vector_NormLen':
./src/base/ftcalc.c:935:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'ft_corner_orientation':
./src/base/ftcalc.c:1040:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftcalc.c: In function 'ft_corner_is_flat':
./src/base/ftcalc.c:1085:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
In file included from ./src/base/ftbase.c:27:
./src/base/ftgloadr.c: In function 'FT_GlyphLoader_New':
./src/base/ftgloadr.c:82:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftgloadr.c: In function 'FT_GlyphLoader_Rewind':
./src/base/ftgloadr.c:98:3: warning: visibility attribute not supported in this 
configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftgloadr.c: In function 'FT_GlyphLoader_Reset':
./src/base/ftgloadr.c:122:3: warning: visibility attribute not supported in 
this configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftgloadr.c: In function 'FT_GlyphLoader_Done':
./src/base/ftgloadr.c:137:3: warning: visibility attribute not supported in 
this configuration; ignored [-Wattributes]
   }
   ^
./src/base/ftgloadr.c: In function 'FT_GlyphLoader_CreateExtra':
./src/base/ftgloadr.c:184:3: warning: visibility attribute not supported in 
this configuration; ignored 

[ft2-demos][win32] Compiler Warnings

[Anuj Verma]

Hello,

There are a couple of warnings in the win32 subsystem of the
freetype-2 demos. I have attached a patch to fix those.

I can also see a lot of the below warning
```
src/base/ftsystem.c: In function 'FT_Stream_Open':
src/base/ftsystem.c:282:3: warning: visibility attribute not supported in
this configuration; ignored [-Wattributes]
   }
   ^
```
I don't know what it is. I think it's specific to windows as I don't
see this on linux. I'm using GCC 8.3.0 and GNU Make 4.3 to
compile on windows.

Anuj


ft2demos.diff
Description: Binary data

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei, Werner,

I have my college exams on 23rd and 24th this month,
and as I haven't prepared for them yet, I would like to
give a few days that are left and study for my exams.
My last exam is on the 24th morning and after that I will
start doing the bitmap to SDF renderer which I think
will not take more than 2 weeks.

Thanks,
Anuj

Re: [freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

[Anuj Verma]

> OK.  What about passing `__LINE__` then?

Alright, I have done the relevant changes, to pass
line through a function parameter I had to change
`FT_DEBUG_INNER' and `FT_ASSIGNP_INNER'
macros like this:
```
  #define FT_DEBUG_INNER( exp )  ( _ft_debug_file   = __FILE__, \
   _ft_debug_lineno = line, \
   (exp) )

  #define FT_ASSIGNP_INNER( p, exp )  ( _ft_debug_file   = __FILE__, \
_ft_debug_lineno = line, \
FT_ASSIGNP( p, exp ) )
```
Is that okay? If there is anything else I need to change
please let me know.

Thanks,
Anuj

Re: [freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

[Anuj Verma]

 > There should be zero overhead for the non-debugging case.
> Having two versions would also allow to use a function internally so
> that you can (a) avoid the `do {} while (0)` construction, and (b)
> still use the macro within a conditional.

I thought about that, but if we create a function then the memory
dump won't print the actual line number and that might make it
harder to find memory leaks.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 >> * `FT_Lookup_Renderer' uses renderer format which is currently
>>   `FT_GLYPH_FORMAT_OUTLINE' for the `sdf' module.  How can
>>make it accept both outline and bitmap glyph format ?
>
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most of the code with the original one.

So, I  started adding the new renderer module for the bitmap to sdf
conversion. Is that okay? i.e. adding a new module named `sdfb'.
Or should I just create another renderer in the same module
and add it to the `module.mk' ? something like this:

```
FTMODULE_H_COMMANDS += SDF_RENDERER
FTMODULE_H_COMMANDS += SDF_BITMAP_RENDERER

define SDF_RENDERER
$(OPEN_DRIVER) FT_Renderer_Class, ft_sdf_renderer_class $(CLOSE_DRIVER)
$(ECHO_DRIVER)sdf   $(ECHO_DRIVER_DESC)signed distance field
renderer$(ECHO_DRIVER_DONE)
endef

define SDF_BITMAP_RENDERER
$(OPEN_DRIVER) FT_Renderer_Class, ft_sdf_bitmap_renderer_class
$(CLOSE_DRIVER)
$(ECHO_DRIVER)sdfb  $(ECHO_DRIVER_DESC)bitmap to signed distance field
converter$(ECHO_DRIVER_DONE)
endef

#EOF
```
Which one do you think is better ? I prefer the second one i.e. adding
another renderer within the `sdf' module. That way I can share some
of the code, whereas creating another module will require me to
rewrite everything.

Thanks,
Anuj

On Wed, Jul 15, 2020 at 10:43 AM Werner LEMBERG  wrote:

>
> > I have added all the optimization modes to the module.
>
> Great, thanks!
>
> > By far the fastest method is to subdivide the curve into a number of
> > line segments.  [...]
>
> OK.  I'm glad that you took the time to implement the various
> algorithms so that we have such a comparison.
>
> > The major downside of the BB and subdivision methods is that they
> > require a considerable amount of memory usage (almost 3x of the size
> > of bitmap) because we need to keep a track of the distances and
> > signs of all the grid points.
>
> I don't think this is an issue.  For other rendering modes like LCD
> there are similar requirements, and platforms that are going to use
> SFDs certainly have plenty of memory.  It would be nice, however, if
> you can add this constraint to the documentation, and, if possible,
> also add a logging message that either predicts the necessary
> (approximate) amount of memory before the computation, and/or the
> actual memory use after generating an SFD.
>
> > I have updated the demo, added bilinear filtering, shape
> > reconstruction and has all optimization modes which can be toggled.
> > I have attached the new list of keys.
> > (https://github.com/preversewharf45/ft2sdf-demo)
>
> Thanks, will test soon.
>
> > For now I would like to hold the outline implementation for now and
> > go to the bitmap implementation.  After that the module can be used
> > to generate SDF from bitmaps directly.  It will be pretty fast and
> > will not require any additional memory other than the bitmap itself
> > at a cost of reduced accuracy.
>
> Excellent.
>
> > However there are a few issues.
> >
> > * `FT_Render_Glyph_Internal' break if the glyph format is already
> >a bitmap.
> >```
> > case FT_GLYPH_FORMAT_BITMAP:   /* already a bitmap, don't do
> anything */
> >   break;
> >```
> > * `FT_Lookup_Renderer' uses renderer format which is currently
> >   `FT_GLYPH_FORMAT_OUTLINE' for the `sdf' module.  How can
> >make it accept both outline and bitmap glyph format ?
> >
> > I don't like the idea of changing the internals of freetype so is
> > there any other way in which this can be done ?
>
> Don't worry about changing the internals!  You know best what to do,
> and we can discuss later whether your solution is the right approach.
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most of the code with the original one.
> Alexei?
>
>
> Werner
>

[freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

[Anuj Verma]

Hello Werner, How is this: https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html ? Sent from Mail for Windows 10 

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

[Anuj Verma]

> What exactly do you mean with 'memory debug > table'?

I was thinking about the debug table that is used
internally in freetype i.e. 'FT_MemTableRec'. But it is internal to
'ftdbgmem.c'

I tried a lot to use some structure to track the
allocations, but it requires a significant amount
of changes to the existing code, so I'll just
approximate the memory usage and output that.

Thanks,
Anuj

On Thu, Jul 16, 2020, 11:23 AM Werner LEMBERG  wrote:

>
> >> I think having a global variable for that is a bad idea, even if it
> >> is only active in debugging mode: If you have multiple threads you
> >> will get nonsense information.  Isn't it possible to add this
> >> variable to one of the existing structures?
> >
> > Thanks for pointing that out.  I can use the memory debug table if
> > it contains the total size allocated?
>
> What exactly do you mean with 'memory debug table'?
>
> > I'll see if I can add it in some existing structure.
>
> OK, thanks.
>
>
> Werner
>

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

[Anuj Verma]

 > I think having a global variable for that is a bad idea, even if it is
> only active in debugging mode: If you have multiple threads you will
> get nonsense information.  Isn't it possible to add this variable to
> one of the existing structures?

Thanks for pointing that out. I can use the memory debug table if it
contains the total size allocated ?
I'll see if I can add it in some existing structure. Meanwhile I have
reverted this commit.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> Ok to remove. This only optimizes mistaken calls to FT_Render_Glyph on
> bitmap fonts. A related question is whether we need FT_LOAD_TARGET_SDF
> for FT_Load_Glyph?

I don't think we need `FT_LOAD_TARGET_SDF', I much prefer loading it with
`FT_LOAD_DEFAULT' and then rendering it separately. However to keep it
consistent with the rest of the renderers we might need to add it.

> I would be less worried about FT_Property_Set if FreeType reserved the
> right to remove (ignore) or change properties when it is reasonable to
> do so, i.e. properties should not be considered a part of API.

Does that mean I shouldn't use `FT_Property_Set' ? For some parameters
such as `spread' there is no other way to dynamically set it.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > I don't think this is an issue.  For other rendering modes like LCD
> there are similar requirements, and platforms that are going to use
> SFDs certainly have plenty of memory.  It would be nice, however, if
> you can add this constraint to the documentation, and, if possible,
> also add a logging message that either predicts the necessary
> (approximate) amount of memory before the computation, and/or the
> actual memory use after generating an SFD.

Alright, I will add a log message about the exact memory used after
generating the SDF. Is there any profiling tool built into FreeType?
If there is the exact time can be logged as well.

> Don't worry about changing the internals!  You know best what to do,
> and we can discuss later whether your solution is the right approach.
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most of the code with the original one.
> Alexei?

Okay, I will probably only need to remove this case statement.
```
case FT_GLYPH_FORMAT_BITMAP:   /* already a bitmap, don't do anything */
   break;
```
And yeah I like the idea of creating a seperate renderer, since it won't
be used much. The only cases I can think of where SDF from bitmap
will be generated is either for bitmap fonts or for glyphs with overlapping
contours( until I add something to remove the overlapps ). So, if it is a
separate module it can easily be disabled.

>> I have updated the demo, added bilinear filtering, shape
>> reconstruction and has all optimization modes which can be toggled.
>> I have attached the new list of keys.
>> (https://github.com/preversewharf45/ft2sdf-demo)
>
> Looks excellent!  Some items for the wishlist of `ftstd`:
>
> * A help menu showing the list of keys.
>
> * Easy navigation to get to large glyph indices easily.

I will later create the demo from scratch, so will add these.

> * It probably makes sense to not allow 'Width' values in
>   reconstruction mode to be larger than '(Spread - 1)' or something
>   similar, emitting a warning if this threshold is reached.  Otherwise
>   you get white boxes without a warning.

Yeah, I forgot about that. The `Width' shouldn't exceed `(Spread - 1)'
Thanks for pointing that out, I will add this while creating the new demo.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > what about adding the other two methods (or one of them) and decide
> which one to choose with an option of the build system ? So one method
> fast build consume more memory than other one which is slower.

Yes, even I thought about that. We can also keep both the methods
and use `FT_Property_Set' to switch between the two, which I am
currently using to compare performance.

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello All,

>> The basic sdf module is done, now that is left is to
>> optimize it, fix bugs etc. I will start by optimizing it.
>> I have decided to test three optimization method:
>> * Bounding box (BB)
>> * Subdivisions
>> * And also a coarse grid method that Behdad suggested.

I have added all the optimization modes to the module.
By far the fastest method is to subdivide the curve into
a number of line segments.The coarse grid method is
the slowest unless I am doing something wrong.
[
  Behdad, I divided the grid into 8x8 coarse grid and then
  to find the relevant edges of the coarse grid I am using
  the spread value and the half diagonal of the coarse grid.
  So if any edge's nearest distance to a coarse grid is greater
  then spread + ( coarse grid diagonal length / 2 ) I discard it.
  It works well and for each coarse grid I am getting around
  4 edges, but it's still pretty slower than the bounding box and
  the subdivision method. If you need more details please let
  me know.
]
The major downside of the BB and subdivision methods is
that they require a considerable amount of memory usage
(almost 3x of the size of bitmap) because we need to keep
a track of the distances and signs of all the grid points.

>> The image is upside down in linux maybe because in linux the y = 0
>> is at the the top which is different from windows. I'll fix it soon
>> while adding bilinear filtering.

I have updated the demo, added bilinear filtering, shape
reconstruction and has all optimization modes which can
be toggled. I have attached the new list of keys.
(https://github.com/preversewharf45/ft2sdf-demo)

For now I would like to hold the outline implementation for
now and go to the bitmap implementation. After that the module
can be used to generate SDF from bitmaps directly. It will be
pretty fast and will not require any additional memory other than
the bitmap itself at a cost of reduced accuracy. However there
are a few issues.

* `FT_Render_Glyph_Internal' break if the glyph format is already
   a bitmap.
   ```
case FT_GLYPH_FORMAT_BITMAP:   /* already a bitmap, don't do anything */
  break;
   ```
* `FT_Lookup_Renderer' uses renderer format which is currently
  `FT_GLYPH_FORMAT_OUTLINE' for the `sdf' module. How can
   make it accept both outline and bitmap glyph format ?

I don't like the idea of changing the internals of freetype so is there
any other way in which this can be done ?

Thanks in advance,
Anuj

- KEYS --

Esc / 'q'  : Quit the program.
   
'z': Scale up (This doesn't change point size, it
 just zoom the image.)
'x': Scale Down (same as above)
   
'Up Arrow' : Increase point size by 1.
'Down Arrow'   : Decrease point size by 1.
'Page UP'  : Increase point size by 25.
'Page Down': Decrease point size by 25.

'Left Arrow'   : Previous Glyph
'Right Arrow'  : Next Glyph

'o': Increase 'spread' by 1.
'l': Decrease 'spread' by 1.

'w', 's',  : Move the glyph Up/Down.
'a', 'd'   : Move the glyph Left/Right.

'f': Toggle between Nearest and Bilinear filtering.

-- OPTIMIZATION MODES --

Press the relevant keys to change the optimization mode.

'1': None (All grid points against all contours
 and all edges.)

'2': Bounding Box (Use BB to improve performance
 by only checking the grid points in the 
 bounding box of a edge.)

'3': Subdivision (Subdivide the curve into lines
 then only check the grid points near the
 line segment) [FASTEST]

'4': Coarse Grid (Divide the area into a number of
 coarse grids and then only check the edges
 relevant to the coarse grid.)

-- RECONSTRUCT IMAGE FROM SDF --

'r': Toggle between Reconstruction and Raw view.

** The keys below are only for Reconstruction mode **
-

'i': Increase Width. (Make the text bolder)
'k': Decrease Width. (Make the text thinner)

'u': Increase Edge. (Increase smoothness around
 the edges, similar to anti-aliasing)
'j': Decrease Edge. (Decrease smoothness around
 the edges, makes the text sharper)

- END --

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 >> You can check out the demo here:
>> https://github.com/preversewharf45/ft2sdf-demo The build process is
>> the same as ft2-demos. The freetype2 library is added as a submodule
>> so use --recursive.
>
> It's actually `--recurse-submodules`..

I think they are both the same. They both do exactly the same thing
for git clone.
The ` --recurse-submodules` was added later to avoid confusion or
something.
https://www.reddit.com/r/git/comments/f26qmf/difference_between_recursive_and_recursesubmodules/

> On GNU/Linux the image is mirrored vertically – do you mean this with
> 'only works properly on Windows'?

No, I was talking about the weird computation differences in linux and
windows which I fixed in this commit:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=anuj-distance-field=36e59b55a603c57146ffbf43b4dc93473e3aaa62
The image is upside down in linux maybe because in linux the y = 0
is at the the top which is different from windows. I'll fix it soon while
adding bilinear filtering.

> Besides that: Very nice!

Thank you very much for checking it out.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > from a mathematical point of view only, you are doing a/64 + b/64
> (this line and also a bit above, which can be factorized like that :
> (a+b)/64. Maybe it is needed to divide first by 64 each term, i don't
> know, i just wanted to point this

I did this to avoid a few divisions and it works fine.

Took me long enough to find out,
The problem was with negating unsigned int.
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sdf/ftsdfrend.c?h=anuj-distance-field#n228
I was subtracting an unsigned int from a signed long
which caused the value to wrap around. It never happened
on windows even with gcc, I'm glad I tested it on linux.

Thanks for your input.

I've updated the demo and it works fine now.

The basic sdf module is done, now that is left is to
optimize it, fix bugs etc. I will start by optimizing it.
I have decided to test three optimization method:
* Bounding box
* Subdivisions
* And also a coarse grid method that Behdad suggested.

Vincent suggested some good tools for profiling. I'm gonna
use linux so if you have any more suggestions please do let
me know, profiling is pretty new to me.
I will also keep updating the demo program.

Thanks for the feedback on the evaluation,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello All,

>> One more thing.  I think the OpenGL demo is not good for everyone to
>> test, so I will working on a demo similar to 'ftview' in my spare
>> time.
>
> Great!

I have created the demo program, it can be used to view raw SDF without
any bilinear filtering and there is no way to reconstruct fonts from SDF
because
again it doesn't have bilinear filtering. I will add that soon.

There is a pretty weird issue that I ran into while testing the demo on
linux
which doesn't happen on windows whatsoever. On linux various computations
give wrong output. For example, division of  -328032 by 64 gives 1811934202,
whereas it should be -5125. Moreover FT_Vector_Length returns negative
values
even for small vectors. There is no overflow so what am I doing wrong?
(One of the places it happens is:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sdf/ftsdf.c?h=anuj-distance-field#n1129
 where the `factor' is wrong after division with 64).

I am using gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
and GNU Make 4.2.1 to build.
If you need more details please let me know.

You can check out the demo here:
https://github.com/preversewharf45/ft2sdf-demo
The build process is the same as ft2-demos. The freetype2 library is added
as a submodule
so use --recursive. And it only works properly on windows. There is no
comments of help
screen so I'm attaching a text file for that.

Thanks,
Anuj
Usage: [ptsize] [font file]

Controls:

q/Esc: Exit

z: Increase Scale by 1
x: Decrease Scale by 1

Up Key   : Increase Pt Size by 1
Down Key : Decrease Pt Size by 1
Pg Up Key: Increase Pt Size by 25
Pg Down Key  : Decrease Pt Size by 25

w: Increase Spread by 1
s: Decrease Spread by 1

Left Key : Previous Glyph
Right Key: Next Glyph

Re: [freetype2] anuj-distance-field 145c3c6 4/4: [sdf] Make squared distances toggleable.

[Anuj Verma]

> Nice idea, thanks!

Thanks. Is it better to make it runtime toggleable
by using a flag ?

> Formatting nit: Please ensure that '#' is always on the first line,
> so:
>
>   #ifndef USE_SQUARED_DISTANCES
>   #  define USE_SQUARED_DISTANCES 0
>   #endif

Fixed.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> Do you know from your floating point version if q3 or r2 is larger
> when this happens? From your description it sounds like q3 is still
> larger than r2.

In this specific case where q3 becomes 0, r2 is always greater than
q3. But generally q3 can be greater than r2 in some cubic equation.

> In this case, if (r2 == 0) is missing here:

I just checked and r2 can also cause underflow, so yeah I should
check r2 == 0. But, this check only reduce the error it does not
eliminate it. I even checked increasing the precision but it still
happens, and increasing precision also creates a risk of overflow.
So, I might have to think of something else.

Apart from that, I thought about another optimization:
Smooth rasterizer is ultra fast, it only takes a few nano-
seconds to render. So we can embolden the outline by
spread, render it with the smooth or monochrome rasterizer
and that will give us all the points that we need to check. It
can pair up well with the bounding box method.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

One more thing. I think the OpenGL demo is not
good for everyone to test, so I will working on a
demo similar to 'ftview' in my spare time.

On Sat, Jun 27, 2020, 8:21 PM Anuj Verma  wrote:

>
> >> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
> >> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
> >> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
> >
> > [for subdivision I equally divided the curve into 16 parts]
> > This is a tie between B and C because you can still find some
> > interesting optimizations
>
> Yes. For now I'll integrate the A method and then start optimizing, and I
> will
> also use some better tools that Vincent suggested for profiling.
>
> > There is another reason why subdividing cound faster: the bounding box
> > of a line is larger than two bounding boxes of its halfs, not
> > considering the padding (spread). However, 16 is too arbitrary. In
> > fact, in our antialiased renderer we divide until the curve deviates
> > from the line no more than 1/8th or a pixel, which could be more or
> > less than 16 depending on the size of the curve and its shape.
>
> I used 16 because It doesn't create jagged edges and looks exactly
> as method A. I believe the smooth renderer uses de Casteljau algorithm
> so I'll use that to subdivide.
>
> >> However, it is not always faster than the bounding box check, If we
> increase the
> >> spread to 16, then it gets a bit slower, because while checking the
> proximity the
> >> number of duplicate checks increases. But I believe that it can be
> avoided by
> >> only checking the grid points that are perpendicular to the line
> segment as you
> >> said in a previous mail.
> >
> > This sort of optimizations can be quite complex to implement though,
> > which might defeat the purpose.
>
> I thought about this, we can align the bounding box in the direction of
> the line,
> that way all the points inside the bounding box will be perpendicular, the
> only
> problem is to actually find the points inside the box, which can be a bit
> tricky.
>
> > Do you understand why the underflow happens? Is it because the curve
> > arches around the point and there exist multiple solutions, perhaps
> > almost an infinite number of solutions? Does the equation with all
> > coefficients substituted become quadratic or linear and you can solve
> > it differently? Your method is still very good.
>
> I explained this to Werner a while ago in this message:
> https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00127.html
> It happens when there is exactly one root of the cubic equiation and
> the curve gets really close so the point. I'm almost sure that It can be
> avoided by increasing the precision, but I haven't tried it yet.
>
> >> Finally, my opinion about subdividing is changed and I say that it's
> definitely worth
> >> subdividing the curve as it increases performance. But, as I said if
> the spread is
> >> more than 8 then it gets slower as of now without any optimizations and
> I still think
> >> we should keep the spread at least 32. So, to clarify weather 8 or 32
> is a good number
> >
> > I wonder if there is a way to test this using some SDF demo tool...
>
> I currently use an OpenGL demo, and in that even a spread of 2
> is enough to draw perfectly, so 8 would be plenty. I just think that
> 32 gives a good range. On the other hand 64 is overkill and it almost
> looks like a circle above 64.
> Either way the subdivision method will work even with 32, so there is
> no problem with the spread now. Moreover what is your opinion about
> implementing both the methods ?
>
> > But for 4 is only 2 bits...I remember you decided to use FT_F2Dot14.
> > What is the correct way of presenting SDF to a client? What is the
> > common practice?
>
> That will have to be changed now, I previously thought of normalizing the
> values, but that is not a good idea. Now, I'm thinking of using something
> like 8.8 and another option of 3.5. That way if the user has low memory
> they can use the 8bit version.
> In skia Jim uses 3.5 so that might be good. I'm still not sure about the
> format
> but that can easily be changed.
>
> Thanks,
> Anuj
>

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

>> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
>> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
>> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
>
> [for subdivision I equally divided the curve into 16 parts]
> This is a tie between B and C because you can still find some
> interesting optimizations

Yes. For now I'll integrate the A method and then start optimizing, and I
will
also use some better tools that Vincent suggested for profiling.

> There is another reason why subdividing cound faster: the bounding box
> of a line is larger than two bounding boxes of its halfs, not
> considering the padding (spread). However, 16 is too arbitrary. In
> fact, in our antialiased renderer we divide until the curve deviates
> from the line no more than 1/8th or a pixel, which could be more or
> less than 16 depending on the size of the curve and its shape.

I used 16 because It doesn't create jagged edges and looks exactly
as method A. I believe the smooth renderer uses de Casteljau algorithm
so I'll use that to subdivide.

>> However, it is not always faster than the bounding box check, If we
increase the
>> spread to 16, then it gets a bit slower, because while checking the
proximity the
>> number of duplicate checks increases. But I believe that it can be
avoided by
>> only checking the grid points that are perpendicular to the line segment
as you
>> said in a previous mail.
>
> This sort of optimizations can be quite complex to implement though,
> which might defeat the purpose.

I thought about this, we can align the bounding box in the direction of the
line,
that way all the points inside the bounding box will be perpendicular, the
only
problem is to actually find the points inside the box, which can be a bit
tricky.

> Do you understand why the underflow happens? Is it because the curve
> arches around the point and there exist multiple solutions, perhaps
> almost an infinite number of solutions? Does the equation with all
> coefficients substituted become quadratic or linear and you can solve
> it differently? Your method is still very good.

I explained this to Werner a while ago in this message:
https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00127.html
It happens when there is exactly one root of the cubic equiation and
the curve gets really close so the point. I'm almost sure that It can be
avoided by increasing the precision, but I haven't tried it yet.

>> Finally, my opinion about subdividing is changed and I say that it's
definitely worth
>> subdividing the curve as it increases performance. But, as I said if the
spread is
>> more than 8 then it gets slower as of now without any optimizations and
I still think
>> we should keep the spread at least 32. So, to clarify weather 8 or 32 is
a good number
>
> I wonder if there is a way to test this using some SDF demo tool...

I currently use an OpenGL demo, and in that even a spread of 2
is enough to draw perfectly, so 8 would be plenty. I just think that
32 gives a good range. On the other hand 64 is overkill and it almost
looks like a circle above 64.
Either way the subdivision method will work even with 32, so there is
no problem with the spread now. Moreover what is your opinion about
implementing both the methods ?

> But for 4 is only 2 bits...I remember you decided to use FT_F2Dot14.
> What is the correct way of presenting SDF to a client? What is the
> common practice?

That will have to be changed now, I previously thought of normalizing the
values, but that is not a good idea. Now, I'm thinking of using something
like 8.8 and another option of 3.5. That way if the user has low memory
they can use the 8bit version.
In skia Jim uses 3.5 so that might be good. I'm still not sure about the
format
but that can easily be changed.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

> I assume spread means maximum distance.

Yes.

> We use a spread of 4, so 8 would be plenty. We use 4 mainly to keep the
glyph sizes under control,
> because a larger spread means a larger pad of texels around each glyph to
make use of that information.

So I guess 8 is enough for now. And btw it will be adjustable.

Thanks for the info,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > you also have DrMemory on Windows memory errors and leaks, and the
> Visual Studio tools
> (
https://docs.microsoft.com/en-us/visualstudio/profiling/getting-started-with-performance-tools?view=vs-2017
)

That would be much more convenient, I'll check these out.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > have you tried to use valgrind's callgrind tool + kcachegrind ? It can
> be very helpful

No, I haven't. The problem is that I use windows for development and
valgrind doesn't work on windows.So, switching back and forth makes
the process a bit tedious. I'll try to use it on WSL2.

Thanks for suggestion,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

I tried the subdivision method that you suggested. I'll start with the
performance.

I generated 100 glyphs with a pixel size of 256 and a spread of 8

A) Checking all grid points:15.43 seconds (~154ms per glyph average)
B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)

[for subdivision I equally divided the curve into 16 parts]

Yes, the subdivision method is the fastest, I was not expecting this to
happen
considering it increases the number of duplicate checks and also increases
the
number of lines. Anyway, it is faster because of obvious reasons (we don't
have
to `solve_cubic_equation' which is the slowest part of the entire process).

However, it is not always faster than the bounding box check, If we
increase the
spread to 16, then it gets a bit slower, because while checking the
proximity the
number of duplicate checks increases. But I believe that it can be avoided
by
only checking the grid points that are perpendicular to the line segment as
you
said in a previous mail.
Moreover the subdivision method gets rid of underflow issues that were
caused
while solving the cubic equation.

The only downside that I can think of is that if we increase the pixel size
ridiculously
then the number of divisions might have to be increased and that might make
the
process slower. But, that is just my intuition and I can't say anything for
sure.

Here is a screenshot (https://i.imgur.com/CUmGLUM.png) which compares the
direct
method to the subdivision method. They look exactly the same. I have also
marked
the effect of underflow on the SDF. The image is a bit large so you might
have to zoom
in to see the artifact.

Finally, my opinion about subdividing is changed and I say that it's
definitely worth
subdividing the curve as it increases performance. But, as I said if the
spread is
more than 8 then it gets slower as of now without any optimizations and I
still think
we should keep the spread at least 32. So, to clarify weather 8 or 32 is a
good number
I'm CCing Jim, as he uses SDF in skia he will be able to tell whether 8 is
enough.
[
  For Jim: Just to make it clear, `spread' is the max distance that will be
present in the final
  SDF output. What is the max spread that you use in your SDF and is 8
enough ?
]

I have uploaded the demo directly and not the separate standalone
implementation
you can check it out here :
https://github.com/preversewharf45/freetype2-sdf-demo
You, can directly go here:
https://github.com/preversewharf45/freetype2-sdf-demo/blob/master/vendor/freetype2-sdf/src/sdfgen.c#L485
to see the subdivision code. And yeah currently I'm subdividing equally
which might
not be good. So using a more efficient algorithm to subdivide the curve
will be better.

Sorry for a large mail and Thanks for your time,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Werner,

> It's not clear to me what you want to achieve.  Please elaborate.

For example If the user wants to enable multi-channel rendering which
gets rid of smooth corners, or to enable SIMD optimization. The simplest
example would be to enable overlapping contour support.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> You probably mean the slight "pulsing" inside. You are right, it
> should not happen. It might be the same effect as the one apparent on
> the miter line, or I am just seeing things.

Yes, it's kind of like discontinuities in the distances. I'll share a
screenshot once I subdivide the conic curve.

> The 8x8 neighborhood has larger distances diagonally than vertically
> or horizontally so they (like all distances) have to be clamped
> accordingly. You should probably also preset (memset) the grid to the
> same cutoff value with appropriate sign for the outside. Keep in mind
> that orientations are different for TrueType and Type1/CFF.

Yeah, I was not clamping them before. Now it looks good apart from the
sign.

> Even if you preset the field to an appropriately signed cutoff, there
> might still be unvisited inside regions of opposite signs. Those can
> be found by one pass over looking for large discontinuities, easily
> fixable by flipping the sign.

Yeah, even I was thinking of doing a single pass of all the rows from left
to right, flipping the distances as I go along. So I will try to implement
it
next. The corner checking still stands, it can't be avoided because at
corners
two lines give opposite signs, so to resolve this the corner checking has
to be
done.

>> Lastly, instead of checking the 8x8 neighborhood of the line segments, I
calculated the
>> bounding box of the line, increased it by 8 in the x and y direction and
used that to
>> calculate the distances. It is still very fast and doesn't result in
that hard edge (https://i.imgur.com/24Rz8eV.png).
>> We can even align the bounding box along the line and create a pretty
tight space. I
>> think it is worth giving it a try as well.
>
> Sure, I like it. This is a good test if splitting is worth anything.

Meanwhile here is the performance of using bounding box:
So, I generated 100 glyphs with a pixel size of 256 (which
in my opinion is more than enough for SDF) using a spread of
16:

* the previous method (checking all grid points): took 18.296 seconds for
all glyphs ( ~182 ms average )
* the bounding box method: took 1.487 seconds for all glyphs ( ~14.8 ms
average )

[I did the test on a ttf font so it only contains lines and conic curves]
They look exactly the same. Moreover the bounding box method can be made
even
faster by aligning it properly.

So, the next thing I'll do is the single pass phase to determine the sign of
unchecked grid points, and then I'll try the subdividing. The code is a
little
messed up right now, so I'll probably push it in 2-3 days.

Also, I was working on the integration part today. I added functionality
to set renderer properties (namely the `spread' parameter).  So, there is
API for this `FT_Property_Set' and `FT_Property_Get'. Is there any similar
API for setting the renderer specific modes which is defined by the
`FT_Renderer_SetModeFunc'
function, or do I get the module from `FT_Get_Module' (`FT_Get_Renderer'
will not return `sdf'
renderer because it has same glyph format as the `smooth' renderer) and
then call the
function manually ?

Thanks for your comments

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> I actually think that it is faster
>
> foreach line
>for proximal gridpoints
>   do work
>
> where proximal is at most 8 grid units away. The rest is truncated
> (clamped) at 8. I am choosing 8 because this is probably enough (or
> not).

I tried this method, and yes it is very (probably a lot) faster than
checking all the
grid points. I did not check the performance but now I can generate 512
pixel size
glyphs within a click. However there are a few issues:
* First, subdividing creates wrong results. I did not try subdividing
bezier curves. For
  start I simply divided the line segments into 8 segments and I generated
SDF in the 8x8
  neighborhood of those segments, but it results in wrong distances at some
points. I don't
  know the exact reason for this so I will try to find it out.
* Second, checking the 8x8 neighborhood causes hard edges. (
https://i.imgur.com/SunxGGU.png)

> The sign is tentative and flips on
> updating the grid depending if it is to the right or to the left of
> the line.

* It is correct to determine the sign this way, but it only determines the
sign of the
  pixels that we are actually checking. There are still points left whose
sign is to
  be determined. We can clamp them to 8, but still the sign has to be
determined. I think
  we can use this for that:
https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp#23

Lastly, instead of checking the 8x8 neighborhood of the line segments, I
calculated the
bounding box of the line, increased it by 8 in the x and y direction and
used that to
calculate the distances. It is still very fast and doesn't result in that
hard edge (https://i.imgur.com/24Rz8eV.png).
We can even align the bounding box along the line and create a pretty tight
space. I
think it is worth giving it a try as well.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Behdad,

> I have.  In 2018 Nicolas Rougier and I presented a mini-course at
SIGGRAPH that covered all the SDF-based experiments of the past 10 / 15
years.
> If you haven't reviewed those, I suggest you do.  Unfortunately there's
no video and the slides are low resolution:
>
>
https://www.slideshare.net/NicolasRougier1/siggraph-2018-digital-typography
>
> In particular, I advise that you read the 2018-Langyel paper, which is
what's in sluglibrary.com:
>
>  http://www.terathon.com/i3d2018_lengyel.pdf
>
> Because if you follow my line of reasoning in my previous messages and
the rest of this message, I'm advising that you implement what basically
will be Lengyel's algorithm on the CPU.

I looked at the SIGGRAPH slides, it is interesting. Thanks for sharing.
I will read the Lengyel paper and will let you know.

> I thought about that a lot and did some research. This is a good summary:
>
>
https://math.stackexchange.com/questions/2432348/what-is-stopping-criteria-for-newtons-method/2433475#2433475
>
> Basically, if the solution is pulled out of [0,1] range, you can clamp
them.  If they keep pulling out again right after clamping, you can
discard.
> That post also suggests that what you are seeing was caused by your
fixed-point limitations.  Were you testing with float or fixed?:

I was testing it with fixed, I will again test it with floats and let you
know. Thanks for sharing the link.

>> * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
> is enough for always finding the closest point.
> >> That would speed up significantly.
>
> > It will certainly speed up the process a lot. But in the current
> implementation here are the results:
> > A) MAX_DIVISIONS=2 : https://i.imgur.com/B9Q8Kpa.png
> > B) MAX_DIVISIONS=4 : https://i.imgur.com/1sbl9MP.png
> > Maybe if I don't break out when the factor falls outside [0.0, 1.0],
> MAX_DIVISIONS=2 might work.
> > But currently there are issues when using MAX_DIVISIONS=2.
>

[note the two images above are constructed using fixed point, I will
specify this from now on]

> I take that back.  Moreover, I'm convinced with 4 you still get very
noticeable artefacts with correctly-constructed fonts.

> When I was thinking through it last time I was mistakenly thinking that
there are three roots, whereas there are five.  Moreover, the positions of
the roots
> can be arbitrarily close to each other. Moreover, there's no fast
criteria to know the quality of the Raphson output or know when to
terminate.  As such, I
> believe the method cannot be made correct (as in not producing artefacts)
and fast at the same time.

If you are talking about the artifact at the corners, it is again caused
only while using fixed-point. Moreover, it also happens
in simple contours with only line segments (https://i.imgur.com/MZsNeHJ.png
- uses fixed). I will try to fix this for fixed-points.
Here is an SDF using floats: https://i.imgur.com/QSGCoIj.png - uses floats
and Raphson

> So I go back to my suggestion earlier on: that you convert cubics to a
series of quadratics.  Note how that conversion needs to be done once only,
not per pixel.
>
> For the conversion I suggest lifting the core ideas from cu2qu:
>
>   https://github.com/googlefonts/cu2qu/issues/10
>
> ideally withe cusp issue handled:
>
>  https://github.com/googlefonts/cu2qu/issues/6

I will try to optimize Newton's method (will also try to remove artifacts)
and will also check the performance of converting cubic to quadratic, then
we can finally decide what to use.

> I understand why you are doing it.  I believe it's not necessary.  Let me
try again.  See if you can prove the following for yourself.
> I have proved it and can share.  (Only if we had a mathematician around
;)).
>
> Lemma: if the closest point on curve [0,1] is to the endpoint at t=1 and
the cubic equation has no real root at t=1, the cubic equation must have at
least one real root at some t > 1.
> Similarly, if the closest point on curve [0,1] is to the endpoint at t=0
and the cubic equation has no real root at t=0, the cubic equation must
have at least one real root at some t > 1.
>
> As such, you just need to compute all real roots, clamp them to [0,1] and
remove duplicates.

[there is a typo, it should be t < 1 at the last point]

I tried to use this and it works exactly the same as before but faster.
Thanks for that.
I can't quite figure out the proof, here is what I think:
The cubic equation here is used to find the perpendicular to the curve.
Now, if we forget about the range [0, 1] the perpendicular can be anywhere.
Moreover, the slope of curve is given by a linear equation ( y = mx + c ),
that means it varies from [-90, 90] (tan(x) varies from [-inf, inf]: this
is also the reason why there has to be at least one real
root/perpendicular).
So, if we extend the endpoints we will get a perpendicular somewhere down
the
line, but I can't figure out why it is at t > 1 if the nearest point is at
t = 1
and vice versa. It will be great if 

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > *I agree with Behdad.  Using functions, even for stuff that gets called*
> *only once, greatly enhances readability of code, among other things.*
> *So please proceed as you plan :-)*

Yes, I will. Thanks

>> *I strongly advise that you reconsider this.*
>
> *We discussed that already, didn't we?*

Yes, I will summarize. For now I will be using fixed points. And later
I will write code specific to platforms which support floats and SIMD.
I hope that is okay.

> *I beg to differ.  A GSoC project is not only to implement one thing in*
> *one way.  It is an opportunity to learn.  Anuj is now seeing both*
> *sides of the fixed-point mathematics medal, so to say; as soon as he*
> *will have mastered the project he knows *exactly* when to use it and*
>
*when to avoid. *

Before this project I never knew there was something like fixed-point. I
knew that at the end of the day floats are also stored in bit array, but
I didn't know that something like this is used until I started working
on this project.
At first it was a bit frustrating to work with them but I have gotten
used to them now. So yeah it has been a good learning opportunity :)

One more thing, shouldn't it be a `minmum level of warnings.' ?
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftgrays.c#n441

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

First thing, here is the result of all the curves after using square
distances:

A) Line Segment: ~0.10 microseconds
B) Conic Curves: ~0.75 microseconds
C) Cubic Curves: ~0.71 microseconds

For comparison, the previous result with `FT_Vector_Length':

A) Line Segment: ~0.32 microseconds
B) Conic Bezier: ~1.08 microseconds
C) Cubic Bezier: ~1.25 microseconds

Secondly, I did try subdividing the conic curves, for start I simply divided
them into equal parts and used that to generate SDF. I saw that it require
at least 32 divisions to produce a decent SDF, which in itself is quite
slower
than simply solving the cubic equation (and there can be many curves in the
glyph).
Moreover, I overlooked the fact that around the corners there is a corner
check
involved, which is done to determine the sign correctly around corners. So,
subdividing the curve also increases that which is around ~0.13
microseconds
for each pixel around the corner.

Looking at this I now think that it's not worth splitting the curve into
lines for
generating the SDF. But I think for optimization it can be used, we can use
a coarse grid and subdivided curves to quickly check which line is closer
to the coarse grid, and then for the pixels in the coarse grid we only check
those curves. This will also not require the corver check since we are only
interested in absolute values. I think this can be faster but can't say
anything
for sure without profiling.

One more thing, shouldn't it be `minmum level of warnings.' ?
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftgrays.c#n441

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > *Ok. This means that square-distance might need [...]*

I agree that 181 is enough in a typical SDF grid, and anyway
if we generate a 8bit SDF bitmap it won't be able to represent
more than 127 signed values.
And I also agree that closer distances are more important than
distant distances if the user is simple using the SDF from simple
reconstruction. But, if we want to generate something like this:
( https://www.ronja-tutorials.com/2018/11/17/2d-sdf-combination.html )
then I think both types of distances are equally important.
By truncating do you mean normalizing in a range of [0, 181] or clamping
the values? In both cases I don't see any problem.

> *As I said above, the distant grid points contain [...]*

So, basically we subdivide the curve into small lines and use them to
generate the SDF, so as to make the process faster.
I will try to implement this tomorrow and see how it looks. And if it
works here is what I propose:

First for the squared distances. While generating SDF, I am using a `spread'
parameter which defines the max distance which will be present in the final
output (basically the output will have a range [-spread, spread]). So, In
case
the spread is small (< 181), we can use the squared distance to generate
the SDF.
And in case it is greater than 181 we simply use `FT_Vector_Length'.

Second if the subdivision method works and is both faster and doesn't
differ much from
the method I am currently using, then we will use it to generate SDF if the
glyph size
is small, because I think if the glyph size is large then there might be
too many
subdivisions and it will make the whole process slow. And if the glyph if
large then
we will use the current method. (of course this will depend if the
subdivision method
doesn't differ much from the actual SDF)

So we use separate implementations depending on the spread and the size of
the glyph.
How does it sound?

>
*Looks alright, including modules.mk . Have you checked
if it compiles? *

Thanks for checking it out. Yes, it does compile,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

First, about using squared distances instead of `FT_Vector_Length', it
is much faster to use squared distance. I tested it with linear case and
it comes around 0.114 microseconds, which is almost 65% faster than the
original time of ~0.32 microsecond. It isn't 90% faster because there is
one vector normalization which can't be avoided.
Moving on, I think it's not possible to store squared distance  using 16.16
fixed point because it can store a maximum of 32668 which is a square of
~181,
so if the glyph is more than that, then there is a problem of overflow. If I
am allowed to use decimal representation instead of binary fixed-point for
internal computation then It might be possible.

> *So each curve is sampled a large number of times [...]*

I'm not sure I understand it correctly, here is what I understood:
You want to divide the curve in a large number of flat segments. Then
calculate the distance of the pixels very near to the curve (the pixels
will have a unique projection on the flat segments and no two will be
the same). Now using these pixels (which have a unique projection),
calculate the distances of the rest of the pixels/grid. Is that correct?

And finally I have a small request, I have added a new `sdf' module in
my branch (
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=anuj-distance-field
)
Can you verify if everything is correct?

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > *Please elaborate.  It's not clear to me what you are referring to, and*
> *what the problem is about.*

If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an ascii
character `0' at pixel size 31, you can see that fixed point deviates from
the actual path slightly, which does not happen in case of float.
Moreover in some glyph (eg: https://i.imgur.com/aLmMPld.png) you can see
that
there are jagged edges.
This happens because of underflow, if you check the `solve_cubic_equation'
function (
https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L490
)
there is a term `q3' which is cube of term `q'. So, in cases where is `q' is
pretty small `q3' becomes zero. And later in the algorithm we have to take
the `cube_root' of the term (q3 + r2) to find the final roots. Now because
of
underflow the impact of `q' on the final output is zero. That is why the
roots
davaiate and we get a wrong value. In some cases the deviation is quite
high.
I can perhaps increase the precision in case `q' is pretty small, or simply
use
Newton-Raphson similar to the cubic curve case.

> *And if there is still some time left for GSoC I suggest that you*
> *explore how to implement overlapping removal in FreeType, based on the*
> *Skia code as Behdad suggested.*

I would certainly love to do that even after GSoC.

Thanks for your explanation of the motive behind using fixed-point and
the summarization. Most of the things are clear to me now, I will start
writing the code as soon as I figure out how to add a new module.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

I forgot to add the gprof output. This is the final mail for sure.
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  us/call  us/call  name
 35.67  1.02 1.02 14600 0.01 0.01  sdf_vector_scale
 29.37  1.86 0.84 129379261 0.01 0.01  sdf_vector_add
 27.98  2.66 0.80  100 0.80 2.85  get_min_distance
  5.25  2.81 0.15 6000 0.00 0.00  sdf_vector_dot
  0.70  2.83 0.02  400 0.01 0.01  sdf_vector_sub
  0.35  2.84 0.01 2100 0.00 0.00  sdf_vector_length
  0.35  2.85 0.01  100 0.01 0.01  sdf_vector_normalize
  0.35  2.86 0.01 main
  0.00  2.86 0.001 0.00 0.00  _GLOBAL__sub_I_main
  0.00  2.86 0.001 0.00 0.00  
__static_initialization_and_destruction_0(int, int)

 % the percentage of the total running time of the
time   program used by this function.

cumulative a running sum of the number of seconds accounted
 seconds   for by this function and those listed above it.

 self  the number of seconds accounted for by this
secondsfunction alone.  This is the major sort for this
   listing.

calls  the number of times this function was invoked, if
   this function is profiled, else blank.

 self  the average number of milliseconds spent in this
ms/callfunction per call, if this function is profiled,
   else blank.

 total the average number of milliseconds spent in this
ms/callfunction and its descendents per call, if this
   function is profiled, else blank.

name   the name of the function.  This is the minor sort
   for this listing. The index shows the location of
   the function in the gprof listing. If the index is
   in parenthesis it shows where it would appear in
   the gprof listing if it were to be printed.

Copyright (C) 2012-2020 Free Software Foundation, Inc.

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.

 Call graph (explanation follows)


granularity: each sample hit covers 2 byte(s) for 0.35% of 2.86 seconds

index % timeself  childrencalled name
 
[1]100.00.012.85 main [1]
0.802.05 100/100 get_min_distance [2]
---
0.802.05 100/100 main [1]
[2] 99.70.802.05 100 get_min_distance [2]
1.020.00 14600/14600 sdf_vector_scale [3]
0.840.00 129379261/129379261 sdf_vector_add [4]
0.150.00 6000/6000 sdf_vector_dot [5]
0.020.00 400/400 sdf_vector_sub [6]
0.010.00 100/100 sdf_vector_normalize [7]
0.010.00 2000/2100 sdf_vector_length [8]
---
1.020.00 14600/14600 get_min_distance [2]
[3] 35.71.020.00 14600 sdf_vector_scale [3]
---
0.840.00 129379261/129379261 get_min_distance [2]
[4] 29.40.840.00 129379261 sdf_vector_add [4]
---
0.150.00 6000/6000 get_min_distance [2]
[5]  5.20.150.00 6000 sdf_vector_dot [5]
---
0.020.00 400/400 get_min_distance [2]
[6]  0.70.020.00 400 sdf_vector_sub [6]
---
0.010.00 100/100 get_min_distance [2]
[7]  0.40.010.00 100 sdf_vector_normalize [7]
0.000.00 100/2100 sdf_vector_length [8]
---
0.000.00 100/2100 sdf_vector_normalize [7]
0.010.00 2000/2100 get_min_distance [2]
[8]  0.30.010.00 2100 sdf_vector_length [8]
---
0.000.00   1/1   __libc_csu_init [315]
[310]0.00.000.00   1 _GLOBAL__sub_I_main [310]
0.000.00   1/1   
__static_initialization_and_destruction_0(int, int) [311]
---
0.000.00   1/1   _GLOBAL__sub_I_main [310]
[311]0.00.000.00   1 

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Werner,

> IMHO, in FreeType, SIMD support is something to be done in addition,
> not as a replacement.  Since Anuj makes quick progress I suggest that
> he first concentrates on the fixed-float route.  If there is some time
> left we should check how SIMD can be implemented.

Just to clarify, ` fixed-float' is the same as `fixed-point' integer?
And yeah, I am interested in adding SIMD support as well!

[sorry for spamming the list, this is the final mail for now]

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> Each curved segment has a large number [...]

I guess this is similar to the Euclidean distance transform algorithm.
http://webstaff.itn.liu.se/~stegu/JFA/Danielsson.pdf

As I said before I will not leave out this option, I will try to implement
this
and then we can compare the performance.

> I am deeply sorry if this mathematical fact offends you in any way.
> Your code is good but please allow me to suggest an alternative,
> perhaps, faster implementation.

Please, don't apologize. I don't find anything offending in your
suggestions.
I realize that we are all in the same boat and we all want to make the
algorithm
as fast as possible. I think we can't comment on which algorithm is better
than the
other without checking the performance and other important factors. So, I
am open to
all of your suggestions and will choose the one that we all can agree on,
same for
`fixed-point' vs `float', same for subdivision or not.

Again Thank you for all of your suggestions,I will require them more in the
future.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

> Also I'm surprised that you haven't put the code get_min_distance code
for each edge type into a function.
> Would you prefer that I comment re these on github?

I don't think that will be necessary. I will fix that while adding in
FreeType. That repository is just for
testing and I might delete it in the future.

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > After you do all this, you will realize that the speed is still a
concern.  Don't do bounding-box check.
> Classic way to do after is to split into a coarse grid and for each cell
find all edges that may be relevant.
> Then for pixels in each cell only process those edges.  This is what
GLyphy does and some of the other solutions as well.

This sounds interesting, I will definitely try to implement this and see
how it performs.

Thanks

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Behdad,

> First, let me congratulate you.  This is a very thorough and impressive
piece of work for such a short time period.

Thank you for that. Viktor's paper did help me a lot while writing the
code. I guess you have already read his paper,
but in case anyone is interested in reading it check this out:
https://github.com/Chlumsky/msdfgen. It contains all
the relevant information for generating SDF from outlines. Although I'm not
using the full potential of the paper currently.

> - I highly suggest you stick to float internally [...]

I still think `float' is a better option for generating SDF, especially in
lower resolution glyphs where fixed-point produces
kind of straight lines instead of smooth curves(which is not noticable if
you look at it briefly). But my concern is that
FreeType doesn't use floats at the moment and I don't think it will be a
good idea to add support for floats just for the
sake of this project.
It's a tradeoff between one thing or the other and I can't decide which
would be the best considering the current state of
library. I would say that I'm inclined on using fixed-point integers just
because FreeType doesn't use them.
Also, why doesn't FreeType use floats? Is it just because of platform which
doesn't have floating point type? or are there
more reasons? This question has been in my mind for quite some time.

> Have you measured performance?  I'm fairly sure the float can be made
both more robust and faster.

I just did, here are the results with compiler optimization turned on using
chrono library:

A) Line Segment: ~0.026 microseconds
B) Conic Bezier: ~0.168 microseconds
C) Cubic Bezier: ~0.469 microseconds

[I have also attached the gprof output in case you are interested. Note
that the gprof output is without any compiler optimization]
To compare it to fixed-point check here:
https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00095.html

> Specially, when and if going for SIMD, you get inverse-sqrt for float but
not int and that seems to be the slowest part of your work, which is
> normalizing vectors. And I agree, you should do everything in
squared-distance, then do a full pass over the results and do the (SIMD if
available)
> sqrt()ing.  I believe you still need normalizing vectors though.

SIMD sounds interesting and will definately be a plus point if I can
implement it. As for squared-distance, it isn't a problem while using float
but in case of fixed-point, I can't store the distance if it is more than
~180 in a 16.16 fixed point without causing overflow.

> - Your Newton-Raphson is solid and your performance numbers look
amazing.  I think you should stick with this approach instead of
subdividing.
> As was suggested by others, do experiment with Raphson on your quadratic
as well.

Yes, will try to use Raphson on quadratic, although I don't think it will
be better than solving the cubic equation. And I will stick to it
until I find something even faster.

> * Currently you abandon as soon as factor falls outside of [0,1].  That's
wrong.  Factor might go out but come back in in the next iteration.

I was doing that initially, but I saw that the factor goes `out' and when
it come back `in' it has the same value as the previous `in' value.
This causes 2 extra passes of a fairly expensive iteration, so I decided to
break if it goes outside the range. But, yeah I will see if
that is wrong and decide accordingly after further testing.

> * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
is enough for always finding the closest point.
> That would speed up significantly.

It will certainly speed up the process a lot. But in the current
implementation here are the results:
A) MAX_DIVISIONS=2 : https://i.imgur.com/B9Q8Kpa.png
B) MAX_DIVISIONS=4 : https://i.imgur.com/1sbl9MP.png
Maybe if I don't break out when the factor falls outside [0.0, 1.0],
MAX_DIVISIONS=2 might work.
But currently there are issues when using MAX_DIVISIONS=2.

> - Your quadratic code always adds t=0 and t=1 as roots. You don't need
to. Only clamp the real roots to [0,1] range and remove duplicates.

That is done to also check the endpoints. There are cases where there are:
A) no real roots of the cubic equation (coefficient of x^3 = 0)
B) all real roots lie within the range [0.0, 1.0]

In these cases it becomes necessary to check the endpoints of the bezier
curve, hence t = 0 and  t = 1.

> - Your handling of two edges meeting at a corner is solid. That's exactly
what we do in GLyphy.
> However, I'm also now convinced that there is no way to produce SDF from
contours that might overlap
> [...]

I did use the winding sum and it works well. But it has issues and as you
said it's not possible to find
distance around the intersection. I see that FreeType rasterizer also has
issues while rendering overlapping
contours in Anti-Aliased mode. So, for now I won't add that this and later
when FreeType has functionality to
resolve overlapping contours I can easily add 

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

> For linear segments, it will save more than 90% according to your
> table. Then you will see that splitting Bezier curves is not such a
> bad option. In general, Bezier curves are used in graphics because it
> is easy to split and flatten them. I would be very surprised if
> distance fields were different in this regard?

Well, I'm not much familiar with the rendering part of bezier curve. In 
distance fields I'm just concerned about finding the shortest distance as 
accurate and as fast as possible.
So I won't leave out your option, in the next few days I'll try to optimize the 
code and then again we can compare the results. I think it will be a good 
option.

Anuj

Sent from Outlook Mobile

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Werner,

Thanks for checking the code and for your comments.

Did you miss the last two mails from Alexei and me?
I missed a few mails a few days ago for no reason and
even got a few duplicate mails.

> *I think he means that the code must be optimized as much as possible*
> *to get fast rendering. In particular, it is important to find and*
> *eliminate hotspots.*

Yes, he wanted to check if it's worth splitting the curves into line
segments to get better performance without losing much details. I did
a performance analysis and have attached it in the previous mail.

> *Some comments to your code.*
> ** What does line 38 do?*

There is no use for that. It was just me checking the accuracy of the
output. I forgot to remove that before committing.

> ** Function `get_min_conour` should probably be called*
>   *`get_min_contour`.  Otherwise please explain in a comment what*
>   *'conour' means.*

Another typo, I did fix it in the header file but forgot in the
source file. Thanks for pointing that out.

> ** Have you thought about iterative solutions to get the cubic roots*
>
*necessary for the quadratic case?  Maybe this would be faster. *

This can be faster because we only need to find the roots within
the range [0.0, 1.0]. So, I will implement an iterative solution
and see how it goes.





* > * Maybe there is a mathematical approximation to solving the >
fifth-grade polynomial.  I don't mean a better root-finding >   algorithm
but a simpler representation of the curves so that we can >   avoid a
fifth-grade polynomial altogether.  The same holds for the >   third-grade
equation, of course. *

I am definitely avoiding the fifth-degree polynomial. If you look the commit
(
https://github.com/preversewharf45/freetype2-sdf/blob/5322b28305b3b1a2d45ef68a057fe97efe113cbb/src/sdfgen.c#L523
)
I was actually solving the fifth-degree polynomial, later I decided to
remove
because it was huge and slow. Now I bisect the curve in four parts and
use newton's iteration to find the closest point on the curve.
So to avoid the third-degree polynomial I can use the exact same method
that I use for cubic-curves, but I checked the performance and it's actually
faster to simply solve the polynomial in case of conic-curves. (in case you
missed the mail:
https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00095.html)

> *PS: Did you have a look at Behdad's `GLyphy` implementation? *

Yes, I did check out `GLyphy'. He converts bezier curves to arcs, but I'm
not sure how he does it. Perhaps he is using this algorithm.
(
https://github.com/preversewharf45/papers/blob/master/Cubic%20curves%20to%20Circular%20arcs.pdf
)

Behdad, It would be great if you tell me more about your algorithm and if
it is faster to convert bezier to arcs and find the signed distance.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > *I am asking you to do some performance analysis. Specifically, would*
> *you** please profile a curve and a straight segment to compare?*

Sure, here is the average of 1 million iteration of computing shortest
distance from a point to both types of curves and line segments:
(using -O3 optimization, measured using chrono library)

A) Line Segment: ~0.32 microseconds
B) Conic Bezier: ~1.08 microseconds
C) Cubic Bezier: ~1.25 microseconds

[I have also attached the gprof output in case you are interested. Note
that the gprof output is without any compiler optimization]

> *We need to know if it is worth simply splitting the curve into a large*
> *number of straight segments. How many straight segments we can afford*
> *and still beat the exact solution.*

In my opinion it's not worth splitting the curves into line segments.
But if there is a way to not check each and every line segment, then
it might be worth giving it a try.

> *Sure, but please use your dedicated branch.*

Yes, I will do that.

Anuj
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  us/call  us/call  name
 57.03  1.38 1.38  8378453 0.16 0.16  ft_trig_pseudo_polarize
 16.12  1.77 0.39  100 0.39 2.38  get_min_distance [for 
cubic curves]
 13.64  2.10 0.33 153570100 0.00 0.00  FT_MulFix_x86_64
  4.55  2.21 0.11  100 0.11 0.11  FT_Vector_NormLen
  2.89  2.28 0.07  8378453 0.01 0.01  ft_trig_prenorm
  1.86  2.33 0.05  7378505 0.01 0.01  FT_DivFix
  1.65  2.37 0.04  8378505 0.00 0.18  FT_Vector_Length
  1.24  2.40 0.03 main
  0.41  2.41 0.01  8378453 0.00 0.00  ft_trig_downscale
  0.41  2.42 0.01 FT_Vector_Rotate
  0.21  2.42 0.01 FT_MulFix

 % the percentage of the total running time of the
time   program used by this function.

cumulative a running sum of the number of seconds accounted
 seconds   for by this function and those listed above it.

 self  the number of seconds accounted for by this
secondsfunction alone.  This is the major sort for this
   listing.

calls  the number of times this function was invoked, if
   this function is profiled, else blank.

 self  the average number of milliseconds spent in this
ms/callfunction per call, if this function is profiled,
   else blank.

 total the average number of milliseconds spent in this
ms/callfunction and its descendents per call, if this
   function is profiled, else blank.

name   the name of the function.  This is the minor sort
   for this listing. The index shows the location of
   the function in the gprof listing. If the index is
   in parenthesis it shows where it would appear in
   the gprof listing if it were to be printed.

Copyright (C) 2012-2020 Free Software Foundation, Inc.

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.

 Call graph (explanation follows)


granularity: each sample hit covers 2 byte(s) for 0.41% of 2.42 seconds

index % timeself  childrencalled name
 
[1] 99.40.032.38 main [1]
0.391.99 100/100 get_min_distance [2]
---
0.391.99 100/100 main [1]
[2] 98.10.391.99 100 get_min_distance [2]
0.041.46 8378505/8378505 FT_Vector_Length [3]
0.330.00 153570100/153570100 FT_MulFix_x86_64 [5]
0.110.00 100/100 FT_Vector_NormLen [6]
0.050.00 7378505/7378505 FT_DivFix [8]
---
0.041.46 8378505/8378505 get_min_distance [2]
[3] 62.00.041.46 8378505 FT_Vector_Length [3]
1.380.00 8378453/8378453 ft_trig_pseudo_polarize [4]
0.070.00 8378453/8378453 ft_trig_prenorm [7]
0.010.00 8378453/8378453 ft_trig_downscale [9]
---
1.380.00 8378453/8378453 FT_Vector_Length [3]
[4] 57.01.380.00 8378453 ft_trig_pseudo_polarize [4]
---
0.330.00 153570100/153570100 get_min_distance [2]
[5] 13.60.330.00 153570100 FT_MulFix_x86_64 [5]
---
0.110.00 100/100 get_min_distance [2]
[6]  

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

[sorry for the late very reply, my internet was down yesterday]

>
* How many times do you have to solve this for each glyph? *

A considerable amount of time. If you want the exact number
it is `width * rows * number_of_conic_curves', without any
optimization.

>
* How many different solutions (aka curve points) do you have to *>
* find for each curved segment? I figure there are a lot of grid-curve
pairs to *>* enumerate with most of the curve segment sampled fairly
frequently... *

This can be as many as 65536, this is tied to the width and rows of
the bitmap being generated. The more the resolution the more curve
points have to be checked.
And yes there are various grid points which correspond to the same
curve point. If the grid point lies on the same perpendicular from the
curve then their curve point might be the same.

> *Do you see where I am going?*

I'm not sure. Are you telling me to use the results of the previous
iteration?

I have fixed the overflow, it was just my stupid calculation mistake.
I was dividing some values by a really small number (close to 0) which
was the cause of overflow. So, I have fixed all the problems that I can
find for now (apart from aligning the outline properly on the grid).

> *As usual you can check it out here (
https://github.com/preversewharf45/freetype2-sdf/tree/FT_Fixed
 )*
> *and the demo here (
https://github.com/preversewharf45/freetype2-sdf-demo
 )*

I have updated the repositories and perhaps I can now start integrating it
into freetype?

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello All,

A progress update. I have ported the entire program to fixed point
and it looks good to me. It's still not perfect and there are places
where overflow can happen ( specifically in function `solve_cubic_equation'
),
so currently I'm working on fixing those.
As usual you can check it out here (
https://github.com/preversewharf45/freetype2-sdf/tree/FT_Fixed )
and the demo here ( https://github.com/preversewharf45/freetype2-sdf-demo )

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

> Not a good sign of numerical stability...

Yep, I have thought about scaling down all the values before
computations where overflow can happen. Moreover, since the final
data is normalized, It won't have any effect on the output.
This is what I did from line segments and it did work without any
overflow. So, I will do the same for bezier curves and see how it goes.

>> Perhaps you have to subdivide the Bezier curves, using the Bezier
>> envelope as a guide?
> I thought about it as well: subdivide Bezier curves until the segments
> are flat enough. The code can be borrowed from FreeType smooth
> renderer stopping short of calculating the coverages.

I haven't thought about subdividing the curves, but I can give it a try
if scaling down doesn't work.

>> Hmm.  The last commit in this tree deletes the code for conic and
>> cubic curves in `get_min_distance`...

That's because I did not port conic and cubic to FT_Fixed yet so I
decided to remove them for now.

Thanks,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello All,


*> Have you figured out FT_Fixed arithmetic? You still use floats in your >
code. I think you should convert to FT_Fixed first. *

So, I have been trying to convert my code to FT_Fixed for a few days now
without any success.
I did manage to use fixed point for shapes with only line segments, but
because of small range
of 16.16 fixed point I have to use 26.6 for intermediate calculations and
because of that it
doesn't look good, (https://imgur.com/kUSIj3y) Here is a comparison between
float on
the right and 26.6 fixed point representation on the left.
As for bezier curves, there is almost always an overflow because while
solving polynomials some
large numbers are involved. I even tried using Newton's approximation, but
it's too slow and still
not as accurate as floating points. I did not try using 64 bit integers
because they are not portable
I guess and because of that I have to create separate implementations for
32 and 64 bit architecture.
So, after comparing both, I prefer floats over fixed points because they
satisfy both range and precision.
I can try using 64 bit integers but I am not sure whether I will be able to
finish the project on time or
not because of separate implementation. I have attached the code below,
note that this is my first time
dealing with fixed points so there might be something that I am not doing
right.

SDF with fixed point:
https://github.com/preversewharf45/freetype2-sdf/tree/FT_Fixed
You can directly go here (
https://github.com/preversewharf45/freetype2-sdf/blob/FT_Fixed/src/sdfgen.c#L579)
to
see the important changes I have made.

To view output: https://github.com/preversewharf45/freetype2-sdf-demo
(already has sdf code)

Anuj

On Mon, Jun 1, 2020 at 7:18 PM Alexei Podtelezhnikov 
wrote:

> Hi Anuj,
>
> > I have written the program, you can find it at:
> https://github.com/preversewharf45/freetype2-sdf
> > To view the output I'm currently using a small OpenGL framework:
> https://github.com/preversewharf45/freetype2-sdf-demo
> > this already has the sdf code.
>
> I like the style. Looks good.
>
> > However there is an issue with the program, the glyphs which contain
> intersecting contours have an issue.
> > (example: https://imgur.com/MxJfAwY)
>
> The intersecting contours used to be discouraged and still quite rare.
> In general, you should assume that fonts have reasonable shapes
> without intersections or wrong contour orientations. It is more
> important that your code deals with thin stems and cursive fonts with
> tiny details like serifs.
>
> > Currently the sign of the distance is determined by the orientation of
> the closest edge, so at places where
> > one contour intersects another the pixel near that contour can be
> specified as outside even though it is
> > inside the shape.
> > To fix this issue I'm thinking of using the winding of the contours, so
> is there any function in freetype
> > to get the winding or something similar?
>
> We only have
> https://www.freetype.org/freetype2/docs/reference/ft2-outline_processing.html#ft_outline_get_orientation
> You can cut the outline into individual contours manually. Keep in
> mind that the orientation is different for TrueType and Type1/CFF
> fonts.
>
> > Also, should I start integrating this in freetype or first fix the issue?
>
> Have you figured out FT_Fixed arithmetic? You still use floats in your
> code. I think you should convert to FT_Fixed first.
>
> Best,
> Alexei
>

Re: GSOC - Distance Fields

[Anuj Verma]

*> The only remaining question is how to represent the final output data.*
* > 8bit?  16bit?*

I am thinking of using 16bit 2.14 to represent the final output data.
Then the external application can convert the data however it wants.

Anuj

Re: GSOC - Distance Fields

[Anuj Verma]

 Hello Alexei,


*> Is 1/65563 not enough accuracy for you? Do not be greedy. What would >
you gain from extra accuracy in the world of discrete pixels?*

1/65563 is quite enough for SDF, my point is that in a 16.16 fixed point
I will only be using 18bits ( 1 for sign, 1 for integer and 16 for
fractional part ) so the rest of the bits will not be used.
But this also gives room to increase the precision to something like
6.26.

Also, is there an easy way to port my existing code to fixed point format.
I am currently thinking of rewriting the entire code from the start because
fixed  point format is a bit confusing for me.


Anuj

Re: GSOC - Distance Fields

[Anuj Verma]

Hello Behdad, Jim,

*> I see that in your implementation you are converting cubics to quadratic
spline. That makes a lot of sense and I support that.*

Is it better to split the cubic bezier into quadratic one? why? Currently I
am using Newton-Raphson's iteration to find the
closest point on cubic curves, which is a bit slow but works well and
produces accurate results. (https://imgur.com/QSGCoIj)

*> I think we do want a 8bit representation at least, and possible a higher
one. *

Currently I am using 32bit floats, but since freetype doesn't use floats I
am
thinking of using 32bit 16.16 fixed point instead. The problem with 16.16
is that
most of the bits in the integer part will not be used because I am
normalizing the
values between [-1.0, 1.0] before outputting the data.
The whole fixed point thing is pretty new to me, so any suggestions will be
greatly
helpful.


Thanks in advance,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Werner,



*> As you like.  The idea is that you can go wild within your branch, and >
that you prepare another, cleaned-up branch for final GSoC submission >
that contains commits in a logical order.*

In that case I will start integrating the feature in FreeType. I have
decided to create a new renderer module and add a render mode accordingly.
And since I have a standalone implementation for generating SDF from
outlines,
I will go ahead and do that first and later I will do it for bitmaps.

Thanks,

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,



*> Great! Without further delay, go ahead and write a standalone program >
that calculates DF for a outline glyph in whatever format you choose > or
is appropriate.*

I have written the program, you can find it at:
https://github.com/preversewharf45/freetype2-sdf
To view the output I'm currently using a small OpenGL framework:
https://github.com/preversewharf45/freetype2-sdf-demo
this already has the sdf code.

However there is an issue with the program, the glyphs which contain
intersecting contours have an issue.
(example: https://imgur.com/MxJfAwY)
Currently the sign of the distance is determined by the orientation of the
closest edge, so at places where
one contour intersects another the pixel near that contour can be specified
as outside even though it is
inside the shape.
To fix this issue I'm thinking of using the winding of the contours, so is
there any function in freetype
to get the winding or something similar?

Also, should I start integrating this in freetype or first fix the issue?


Anuj

Re: resizable ft2demos

[Anuj Verma]

> Ok. They also say that PostQuitMessage should get me out of any modal
loop.

That doesn't seem to be stopping the modal loop when I tested it. And even
if you
break out of the modal loop the window won't resize properly.

Also, the application crashes when the width/height becomes zero.
So it should check the values of width/height before
`gr_win32_surface_resize'
in the `WM_SIZE' message.


Anuj

Re: resizable ft2demos

[Anuj Verma]

A callback function would be definitely much better and simpler than my
solution.


Anuj

Re: resizable ft2demos

[Anuj Verma]

I have attached the diff of my implementation. I have handled the SC_SIZE
message
and resize the window manually in a non blocking way.


Anuj


changes.diff
Description: Binary data

Re: resizable ft2demos

[Anuj Verma]

> Is that true? Handling WM_SIZING alone was not enough.

No, simply handling WM_SIZING or WM_SIZE is not enough in the current
scenario.
There is a separate system message SC_SIZE under the WM_SYSCOMMAND
(https://docs.microsoft.com/en-us/windows/win32/menurc/wm-syscommand) which
is
posted when the user tries to resize the window.

Currently the DefWindowProc handles the SC_SIZE command and it goes into a
loop
while the window is being resized. So, you need to handle this message and
resize the
window manually according to the mouse position.

I'll try to implement this and let you know.


Anuj

Re: resizable ft2demos

[Anuj Verma]

The window enters a modal loop whenever you start resizing the window, the
loop terminates when the mouse is released.
more on this here:
https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-entersizemove
So I think the solution would be to handle the "WM_SYSCOMMAND" message and
manually resize the window. You can
also integrate this code. (
https://sourceforge.net/p/win32loopl/code/ci/default/tree/)

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello David,

I took Alexei's advice and have already started writing the standalone
implementation. You can check it out here:
https://github.com/preversewharf45/freetype2-sdf.

Thanks,

Anuj

On Mon, May 18, 2020, 12:20 PM David Turner  wrote:

> I agree with Alexei that it's probably a good idea to start writing a
> prototype with whatever language / format you feel the more fluent first so
> we can look at the algorithms and the outputted data.
> This can later be rewritten into something more FreeType-specific (e.g.
> fixed-floats are better than floats if you have simple ranges like
> [-1.0..1.0] in general).
>
> - David
>
> Le mer. 13 mai 2020 à 16:59, Alexei Podtelezhnikov  a
> écrit :
>
>> On Wed, May 13, 2020 at 10:37 AM Anuj Verma 
>> wrote:
>> >
>> > > What do you need from FreeType to calculate DF?
>> > > Do you see or know
>> > where to find everything you need?
>> >
>> > I will need the bitmap and/or the outline depending upon the type of
>> font. And yes I know where to find those. They both can be accessed from
>> FT_Face.
>>
>> Great! Without further delay, go ahead and write a standalone program
>> that calculates DF for a outline glyph in whatever format you choose
>> or is appropriate. This is a lot of work by itself. How are you going
>> to calculate it straight from Bezier outlines should concern you much
>> more than memory issues.
>>
>> We can think about integrating it into FreeType ,once you have a
>> standalone implementation.
>>
>> Alexei
>>
>>

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

> What do you need from FreeType to calculate DF?
> Do you see or know
where to find everything you need?

I will need the bitmap and/or the outline depending upon the type of font.
And yes I know where to find those. They both can be accessed from FT_Face.

Anuj


On Wed, May 13, 2020, 7:59 PM Alexei Podtelezhnikov 
wrote:

> >
> > > Ah, the (assumed/estimated) number of the pixels should be discussed
> > > for first... Anuj, please give us some informations.
> >
> > The output DF will be slightly larger than the original one (20-30% in
> dimension) to contain the spread.
>
> Anuj,
>
> Let's stop discussing such minor details. Nothing stops you from
> allocating as much memory as you want to store DF or to choose between
> float and FT_Fixed. First please answer the following question as best
> you can.
>
> What do you need from FreeType to calculate DF? Do you see or know
> where to find everything you need?
>
> Alexei
>

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 >> What exactly do you mean with 'stored as something like PNG'?  Is this
>> the output that FreeType returns to the calling application?  Or is
>> this a temporary storage within FreeType?  In both cases I'm not sure
>> that this is the best solution, since compression and decompression
>> costs a lot of time.

I am talking about the output that FreeType returns to the calling
application.
So, there can be a scenario where the external application first generates
and save the output
of the DF (distance field) to a file. And then later on some other external
application loads that file and uses it.
This scenario is common in games where a pre-generated DF is loaded and
used, to reduce load times.

> My understanding is that Anuj is planning to store the rasterized-then-
> blurred glyph images as the extra TrueType table, aslike sbix table.
> I slipped to think about the size of the memory buffer to store these
> data. I'm not in full understanding about "how to use that".

No, I am not planning to save the output as a TrueType table. Initially I
thought
that FreeType supports saving glyph bitmaps to file. But Alexei clarified
that.
So now I think the saving part can be left to the external application to
decide.

>>  What 'image' dimensions are we talking about?
>> Usually, Freetype glyph bitmaps are very small, and compressing them
>> would be a complete waste of time.

> Ah, the (assumed/estimated) number of the pixels should be discussed
> for first... Anuj, please give us some informations.

The output DF will be slightly larger than the original one (20-30% in
dimension) to contain the spread.

Also, I can see **Message not available* *after my emails in the
freetype-devel archives. Am I doing something wrong?

Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Suzuki,

> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed
(16Dot16, 32bit).

I think using FT_F2Dot14 will be a good option because the signed distance
field will have a range [-1.0, 1.0].
But for now I'll stick with *float* as you suggested.

> BTW, the most biggest trade-off in your mind is the size
> of extra table (in TrueType font file) to store Distance
> Fields info? Or, the speed to calculate the Distance Fields
> info?

Usually distance fields are stored as an image (e.g.
https://i.imgur.com/ruWAhT3.png).
And since each pixel in the distance field is the distance to the nearest
edge/outline there
can be more than 255 values. So, in this case the trade-off can be the
accuracy of the distance.
But, on the other hand, I think 255 values might be enough because they are
interpolated if a
point lies between two.

> *This is just my idea without deep thinking*, XML or JSON
> (or, compressed version of them) would be considerable option
> to store the data, during the development of the initial
> draft, because it is easy for them to change the data
> format, insert or remove some extra data. Also it would be
> easy for external programs to extract or manipulate.

This is interesting, I haven't thought about storing them as XML or JSON.
This option can be good if the parsing time is less than the generation
time,
otherwise the external application can directly generate the distance field.
We can also store them in some format which support floating point (e.g.
hdr)

But, for now I think the storing part can be postponed until we have
compared the
accuracy. If there isn't a much difference in the accuracy of floats vs
integers, then
we can simply use 8 bits per pixel and store them as something like PNG.
What do you think about this?

Thanks,

Anuj

On Wed, May 13, 2020 at 9:03 AM suzuki toshiya 
wrote:

> Dear Anuj,
>
> I think you can use *float* directly in the initial draft.
>
> When we merge the implementation using the float type into
> the official public release, we should discuss the design.
>
> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit)
> and FT_Fixed (16Dot16, 32bit). But yet we don't know which
> is the most appropriate for your Distance Fields project,
> or we need another type, thus starting with direct usage
> of float would be safer to keep the all possibilities.
>
> BTW, the most biggest trade-off in your mind is the size
> of extra table (in TrueType font file) to store Distance
> Fields info? Or, the speed to calculate the Distance Fields
> info?
>
> *This is just my idea without deep thinking*, XML or JSON
> (or, compressed version of them) would be considerable option
> to store the data, during the development of the initial
> draft, because it is easy for them to change the data
> format, insert or remove some extra data. Also it would be
> easy for external programs to extract or manipulate.
>
> Regards,
> mpsuzuki
>
> Anuj Verma wrote:
> > Thank you all for the comments.
> >
> > I too agree with Werner.
> > I think comparing both the types seems to be a good option, So, I'm
> gonna do as Suzuki suggested
> > and use floats for my initial draft and later without floats.
> > And I'm not gonna focus on the saving part because the user can always
> do a conversion.
> >
> > Also, can I directly use *float* or use FT_Fixed?
> >
> > Thanks,
> >
> > Anuj
> >
> >
> > On Wed, May 13, 2020 at 5:47 AM suzuki toshiya <
> mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> > Dear Anuj,
> >
> > I agree with Werner's comment.
> >
> > It might be uncomfortable for you to leave an untested question,
> something
> > like "if I use a floating point calculation, the result could be
> better?".
> >
> > Please use a floating point in your initial draft (if you want),
> > and let's discuss about the trade-off with the implementation
> > with no floating point, in later.
> >
> > Regards,
> > mpsuzuki
> >
> > On 2020/05/13 6:14, Alexei Podtelezhnikov wrote:
> >> I'll just add references below.
> >>
> >> On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG  w...@gnu.org>> wrote:
> >>>> I can't decide which format to use for storing the SDF(signed
> >>>> distance fields).  I think using floating-point values (fixed-point
> >>>> in this case) for generation will be more accurate than using
> >>>> integer, but then saving the SDF to a file will require a
> >>>> conversion.
> >> The basic types are described here:
> >>
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Thank you all for the comments.

I too agree with Werner.
I think comparing both the types seems to be a good option, So, I'm gonna
do as Suzuki suggested
and use floats for my initial draft and later without floats.
And I'm not gonna focus on the saving part because the user can always do a
conversion.

Also, can I directly use *float* or use FT_Fixed?

Thanks,

Anuj


On Wed, May 13, 2020 at 5:47 AM suzuki toshiya 
wrote:

> Dear Anuj,
>
> I agree with Werner's comment.
>
> It might be uncomfortable for you to leave an untested question, something
> like "if I use a floating point calculation, the result could be better?".
>
> Please use a floating point in your initial draft (if you want),
> and let's discuss about the trade-off with the implementation
> with no floating point, in later.
>
> Regards,
> mpsuzuki
>
> On 2020/05/13 6:14, Alexei Podtelezhnikov wrote:
> > I'll just add references below.
> >
> > On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG  wrote:
> >>> I can't decide which format to use for storing the SDF(signed
> >>> distance fields).  I think using floating-point values (fixed-point
> >>> in this case) for generation will be more accurate than using
> >>> integer, but then saving the SDF to a file will require a
> >>> conversion.
> >
> > The basic types are described here:
> >
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.htmldata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871sdata=%2FVbt%2BfNz6x24eJNK9ag1PDhZXz49rS4b64fcmMJ2G9A%3Dreserved=0
> > The computations are described here:
> >
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.htmldata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871sdata=T%2BQR9KKVWo%2BEI4Lqr5vFkgguWHV8xm8BB3USWcaQ8iY%3Dreserved=0
> > Saving files is not of FreeType's business. We just return data.
> >
> >> The basic question is whether the accuracy is really needed.
> >> Currently, FreeType doesn't use floating-point arithmetics.
> >> Personally, I would favour a solution without floats, but maybe there
> >> are good reasons for using them.
> >
> >
>
>

Re: GSOC - Distance Fields

[Anuj Verma]

 Hello Alexi, Suzuki,

I can't decide which format to use for storing the SDF(signed distance
fields). I think using floating-point values (fixed-point in this case) for
generation will be more accurate than using integer, but then saving the
SDF to a file will require a conversion.
So there can be few things,
* Generate the SDF in floating-point values and then do a conversion while
saving. (also a new pixel mode has to be added for this)
* Generate the SDF in some other format which can be saved directly (e.g.
unsigned byte). This will reduce the accuracy.

What do you think?

Thanks,

Anuj

GSOC - Distance Fields

[ANUJ VERMA]

Hello Alexi, Suzuki,

I found a slightly better method to generate distance fields from bitmap.
So, instead of the original proposed idea I want to use this instead. Is
that okay?
The method basically approximates edges/outlines from anti-aliased bitmaps,
I have linked the paper in case you want to look at it.

Original Paper: http://weber.itn.liu.se/~stegu/aadist/edtaa_preprint.pdf

Thanks,

Anuj

Re: [Freetype-devel] Re: GSOC

[ANUJ VERMA]

Hello Alexei,
Thanks for the mail!

> It would be a separate FT_Renderer module.
> The only change in FreeType might be FT_RENDER_MODE_DF, or maybe, some
interface to add that dynamically.

This is what I have planned to do for vector fonts, since the FT_Renderer
module converts glyph's outline to bitmap.
And for bitmap fonts I will add something like FT_Bitmap_Convert which will
convert the existing bitmap to distance field.
Please correct me if I am wrong.

> It is highly desirable to use version control to track your work
progress, for example, with git.

Can I create a separate branch in the freetype2 repository as suggested by
Werner? (
https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00033.html)

> * I ask you to put your stuff into a private branch called
> 'xxx-projectname', with 'xxx' identifying yourself and 'projectname'
> your preferred project name).  If necessary, create more branches to
> your liking with similar names

Although I don't understand 'private branch'. Are you talking about local
branch? What am I missing here?

Thanks,

Anuj

Re: [Freetype-devel] Re: GSOC

[ANUJ VERMA]

Hello Nikhil,

Thanks for the information. I will check it out and see how it goes.

Anuj

On Wed, May 6, 2020 at 11:47 AM Nikhil Ramakrishnan <
ramakrishnan.nik...@gmail.com> wrote:

> Hello Anuj,
>
> > > Does your computer have sufficient storage to install "Windows
> Subsystem for Linux" ?
> >
> > I do have linux installed alongside windows (dual boot). But I mostly
> use Linux for testing cross platform applications or writing code specific
> to Linux.
> > It's just that I have used Visual Studio since I started programming and
> I am most comfortable with it. But if it is necessary I will switch to
> Linux.
>
> I have found that Windows Subsystem for Linux (WSL) works well for
> building FreeType and testing your module(s), if your preferred
> development environment is Windows. You could have the repository set
> up in your Windows file system (please mind the line-ending
> differences while committing) and compile FreeType from WSL by
> accessing your Windows drive (should be mounted as `/mnt/ letter>` in WSL). You should also be able to use debugging and memory
> testing tools from WSL if needed.
>
>
> Nikhil
>

Re: [Freetype-devel] Re: GSOC

[ANUJ VERMA]

 >> I was wondering if I could tweak the timeline a little bit? I will
follow it as much as I can, but just in case I am running late or early.

> Please don't mind about the timezone difference, and please keep your
best timezone.
> Both of your mentors (I and Alexei) are living in different timezone,
> and even if you could follow my timezone, it does not guarantee the
minimization of
> the delay in the communication (the mentors are not full-time worker for
FreeType).

Sorry for the confusion, I actually wanted to ask about the schedule that I
have written in my proposal.
For example I have written that by 26th June I will finish the bitmap
implementation. Although I'm sure
that it won't take more than 26 days but in case it takes more than that or
less, then is it possible to tweak the schedule?

> Does your computer have sufficient storage to install "Windows Subsystem
for Linux" ?

I do have linux installed alongside windows (dual boot). But I mostly use
Linux for testing cross platform applications or writing code specific to
Linux.
It's just that I have used Visual Studio since I started programming and I
am most comfortable with it. But if it is necessary I will switch to Linux.

>  Do you use existing project file in the source tree? Or, do you use
CMake?

Yes, I use cmake.

On Wed, May 6, 2020 at 11:08 AM suzuki toshiya 
wrote:

> Dear Anuj,
>
> > I was wondering if I could tweak the timeline a little bit? I will
> follow it as much as I can, but just in case I am running late or early.
>
> Please don't mind about the timezone difference, and please keep your best
> timezone.
> Both of your mentors (I and Alexei) are living in different timezone,
> and even if you could follow my timezone, it does not guarantee the
> minimization of
> the delay in the communication (the mentors are not full-time worker for
> FreeType).
>
> > I mostly use Visual Studio on Windows 10 for development but if there is
> something else I should use, please let me know so that I can learn that in
> the meantime.
>
> Does your computer have sufficient storage to install "Windows Subsystem
> for
> Linux" ?
> There are many FreeType developers working with Unix-like systems, so
> having an
> access
> to some GNU/Linux system (no need to stick to WSL. some virtual machine,
> some
> separated
> machine etc would work) would be good.
>
> BTW, if your daily development is Visual Studio, how do you build FreeType
> on
> your system?
> Do you use existing project file in the source tree? Or, do you use CMake?
>
> Regards,
> mpsuzuki
>
> ANUJ VERMA wrote:
> > Hello Suzuki,
> >
> > I was wondering if I could tweak the timeline a little bit? I will
> follow it as much as I can, but just in case I am running late or early.
> > And is there a set of tools I should use. I mostly use Visual Studio on
> Windows 10 for development but if there is something else I should use,
> please let me know so that I can learn that in the meantime.
> >
> > Thanks,
> > Anuj
> >
> > On Tue, May 5, 2020 at 10:32 AM suzuki toshiya <
> mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>> wrote:
> > Dear Anuj,
> >
> >> Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
> >
> > "Suzuki" is sufficient! Please don't mind about the honorifics, I'm not
> a native
> > (or good) English user :-).
> >
> >> I have a lot of questions and things to understand about the workflow,
> so can I ask them here only or is there a separate mailing list for that ?
> >
> > I guess, other GSoC students might have similar questions in the early
> phase, so
> > please let's start here. When our discussion is sufficiently specific to
> the
> > distance fields, let's move to somewhere else. But, if you want to have
> some
> > non-public e-mail list (and non-public archive?), please let me know. I
> would
> > try to find something.
> >
> > Regards,
> > mpsuzuki
> >
> > ANUJ VERMA wrote:
> >> Hello,
> >> Should I call you Suzuki or Sir Suzuki ? Which do you prefer?
> >> Thanks for the quick response.
> >>
> >>> So the most stable communication for me is still e-mail, or, the
> issues & discussions in github- (or gitlab- etc) systems. What is your
> favorite?
> >> I don't really have a favorite yet, but I do like e-mail and since we
> are located in different time zones I think e-mail would be the best option.
> >> I have a lot of questions and things to understand about the workflow,
> so can I ask them here only or is there a separate mailing list for that ?
> >>
> >> Thanks,
> >> Anuj
> >>
> >>
> >
>