freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Werner LEMBERG
Subject: Re: [Freetype-devel] Re: GSOC - Distance Fields
Date: Wed, 13 May 2020 08:20:49 +0200 (CEST)

> Oh, I see the value to be stored is in a range [-1.0, 1.0].
> I want to hear the comments from other developers :-),
> whether the initial implementation should be FT_F2Dot14 (16bit)
> or float (32bit, at least).

Well, we have dropped 16bit support already, so it's only a question
about storage size.

>> 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?
> 
> If the Distance Fields should be stored as an image (PNG, or
> something like that), I want to withdraw my shallow idea.  XML and
> JSON are not the best options to store the image (using dataURL and
> base64 bitstream? what a stupid idea!), please ignore that.

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

Another use case might be that the calling application provides a
pre-allocated buffer.  In such a situation compression is wrong, too,
since FreeType will simply fill the buffer with data.

Please elaborate.


    Werner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]