Re: [ft] Faster computation of text width?

2015-03-18 Thread John Found 
On Thu, 19 Mar 2015 09:24:55 +1300
Lawrence D'Oliveiro  wrote:

> On Wed, 18 Mar 2015 12:12:26 +0200, John Found wrote:
> 
> > In fact, the cache code is so useful, that not developing it is a
> > huge mistake.
> 
> I think a lot of the heavier-duty FreeType clients do their own
> caching. E.g. Cairo has cairo_scaled_font_t.
> 

Indeed, this was the first I wanted to do reading the FreeType documentation 
and tutorials. 
It is really not very clear about the caching sub-system. Only some experiments 
allowed to
understand how to use it.

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-18 Thread Werner LEMBERG 

> I came across “The Little Manual of API Design” recently
> , from one of the Qt
> developers.

Thanks.


Werner
___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-18 Thread Lawrence D'Oliveiro 
On Wed, 18 Mar 2015 11:54:33 +0100 (CET), Werner LEMBERG wrote:

> Additionally, I'm bad at designing APIs...

I came across “The Little Manual of API Design” recently
, from one of the Qt
developers.

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-18 Thread Lawrence D'Oliveiro 
On Wed, 18 Mar 2015 12:12:26 +0200, John Found wrote:

> In fact, the cache code is so useful, that not developing it is a
> huge mistake.

I think a lot of the heavier-duty FreeType clients do their own
caching. E.g. Cairo has cairo_scaled_font_t.

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-18 Thread Werner LEMBERG 
> If the ABI can only be introduced and never removed, every library
> early or later will become an overbloated huge monster, that no one
> wants to use.  In this moment will come some "lightType" library,
> that will replace the old dead one.

Correct.  There are ideas to provide a lighter interface for a
forthcoming FreeType 3, but this won't come quickly.  Additionally,
I'm bad at designing APIs...

> In fact, the cache code is so useful, that not developing it is a
> huge mistake.

Volunteers welcomed!

> On the other hand, its functions are so different than the other
> FreeType functions, that maybe it worth to make them a separate
> library...

Mhmm, probably not very useful, since it is tightly integrated to
FreeType.  If you don't need its functionality it is easy to
deactivate this module.

> BTW, if the author discarded this task, how the "beta" will become
> "release"?

`Beta' essentially means that I reserve the right to apply larger
changes if necessary.  On the other hand, the caching code is probably
widely used, and changes to it would be an unpleasant surprise to many
users.


Werner

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-18 Thread John Found 
On Wed, 18 Mar 2015 09:55:52 +0100 (CET)
Werner LEMBERG  wrote:


> This is not possible since both structures are public, and for ABI
> reasons they can't be changed.[*]
> 

If the ABI can only be introduced and never removed, every library early or 
later
will become an overbloated huge monster, that no one wants to use. 
In this moment will come some "lightType" library, that will replace the old 
dead one.


> Not really – David Turner, the father of the caching code, no longer
> works on FreeType, and my priorities are elsewhere.  However, if
> someone contributes such code, I will gladly integrate it.
> 

In fact, the cache code is so useful, that not developing it is a huge mistake.
On the other hand, its functions are so different than the other FreeType
functions, that maybe it worth to make them a separate library...
It's so pity the original author leave this work unfinished...

> 
> [*] Well, theoretically they could be changed since the FreeType's
> cache interface is still tagged as beta, but I don't see a
> convincing reason to do it.

What is more convincing than cleaning up the ABI of a beta version and making it
more consistent?
BTW, if the author discarded this task, how the "beta" will become "release"?

Best regards.

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-18 Thread Werner LEMBERG 

>> And if you have really found a bug, it is a great aid to me for
>> debugging and thus very efficient also – only a failing snippet can
>> *exactly* demonstrate the issue.
> 
> No, I don't think I found some bugs.  My questions are about
> FreeType use.  As long as the documentation describes only the less
> efficient way of FreeType use, I have no other choice than trying
> myself and asking questions.

Unfortunately, I have difficulties to talk about efficiency if I can't
see corresponding C (or C++) code.  Maybe somebody else can give you
better advice.

> Ah, BTW, I have a library architecture observation/note:
> 
> The structures FTC_ScalerRec and FTC_ImageType are in practice the
> same structure, described in some different way.  Then why not to
> join them (add a field .flags to FTC_ScalerRec)?

This is not possible since both structures are public, and for ABI
reasons they can't be changed.[*]

> The same applies for the pairs of functions
> FTC_ImageCache_Lookup/FTC_ImageCache_LookupScaler and
> FTC_SBitCache_Lookup/FTC_SBitCache_LookupScaler.

Ditto.

> And last: In the documentation, I read that "We hope to also provide
> a kerning cache in the near future."  Is these plans still alive?

Not really – David Turner, the father of the caching code, no longer
works on FreeType, and my priorities are elsewhere.  However, if
someone contributes such code, I will gladly integrate it.

Werner


[*] Well, theoretically they could be changed since the FreeType's
cache interface is still tagged as beta, but I don't see a
convincing reason to do it.
___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-14 Thread John Found 
On Sat, 14 Mar 2015 05:48:44 +0100 (CET)
Werner LEMBERG  wrote:

> And if you have really found a bug, it is a
> great aid to me for debugging and thus very efficient also – only a
> failing snippet can *exactly* demonstrate the issue.

No, I don't think I found some bugs. My questions are about FreeType use.
As long as the documentation describes only the less efficient way of FreeType 
use,
I have no other choice than trying myself and asking questions.

Ah, BTW, I have a library architecture observation/note:

The structures FTC_ScalerRec and FTC_ImageType are in practice the same 
structure,
described in some different way. Then why not to join them (add a field .flags 
to FTC_ScalerRec)?

The same applies for the pairs of functions 
FTC_ImageCache_Lookup/FTC_ImageCache_LookupScaler and
FTC_SBitCache_Lookup/FTC_SBitCache_LookupScaler.

One of the pair is actually redundant.

And last: In the documentation, I read that "We hope to also provide a kerning 
cache in the near future."
Is these plans still alive? 

Best Regards.

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-13 Thread Werner LEMBERG 

>> Uh, oh, please provide a C snippet, and tell us which font you are
>> using.  I apologize for not being able to work with ASM.
>
> The cited benchmarks was made using "DejaVu Sans" with 16px height
> (19px line spacing)

OK.  This information already excludes a potential issue with CFF
files, cf. https://savannah.nongnu.org/bugs/?43248, which I still have
to investigate in more detail.

> About the C snippets - unfortunately, I can only read C and only if
> it is not so complex.  This way I simply can't provide C code
> snippets at all.  I can write them in Pascal, but writing everything
> from scratch only for a mailing list question is IMHO not very
> efficient.

Believe it or not, it *is* efficient.  In about three of ten cases,
people who try to provide such a snippet discover a bug in their own
code while doing so.  And if you have really found a bug, it is a
great aid to me for debugging and thus very efficient also – only a
failing snippet can *exactly* demonstrate the issue.


Werner
___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-13 Thread Lawrence D'Oliveiro 
On Fri, 13 Mar 2015 22:05:44 +0200, John Found wrote:

> About the C snippets - unfortunately, I can only read C and only if
> it is not so complex. This way I simply can't provide C code snippets
> at all.

The computing world does not revolve around x86. Open-source software
regularly also runs on architectures like ARM and MIPS (both I think
particularly relevant for an embedding-targeted project like FreeType),
and even less common ones like PowerPC.

You may not realize it, but ARM chips alone currently outship x86 by
about 20:1. Or, to put it another way, more ARM chips ship per year
than the entire population of the Earth. Even MIPS chips ship more than
x86, making the latter only the number 3 computer architecture in the
world.

So with all this variety of hardware, writing things in assembly is
usually not practical. Like it or not, C is the lingua franca of
open-source development. Other languages are commonly found too (e.g.
Python, which I used for my FreeType-related project), but C remains
the common denominator.

So take the time to learn C: think of it as an investment in your own
future.

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-13 Thread John Found 
On Fri, 13 Mar 2015 19:51:16 +0100 (CET)
Werner LEMBERG  wrote:

> 
> > Indeed, working more on this issue I realized, that using
> > FT_ADVANCE_FLAG_FAST_ONLY together with FT_LOAD_TARGET_LCD causes
> > FT_Get_Advance to fail always.  Removing FT_ADVANCE_FLAG_FAST_ONLY,
> > makes it work but very slow.
> > 
> > On the other hand, using FT_LOAD_NO_HINTING makes it to work really
> > fast, but the computed width is not the same as the width of the
> > rendered string with hinting enabled.
> > 
> > Which makes this function almost useless in the real world... :(
> 
> Well, caching is the solution.  Additionally, in case a font has a
> hdmx table, and you are in non-ClearType mode, you can use the
> pre-computed advance widths for a given PPEM value.
> 

Unfortunately, I need a general solution working acceptably fast for 
all fonts and rendering modes. This way, it is obviously, that using
FT_Get_Advance is not what is needed and the best solution is to use
the caching sub-system with already rendered images.


> Uh, oh, please provide a C snippet, and tell us which font you are
> using.  I apologize for not being able to work with ASM.

The cited benchmarks was made using "DejaVu Sans" with 16px height 
(19px line spacing)

About the C snippets - unfortunately, I can only read C and only if it 
is not so complex. This way I simply can't provide C code snippets at 
all. 
I can write them in Pascal, but writing everything from scratch only
for a mailing list question is IMHO not very efficient.

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-13 Thread Werner LEMBERG 

> Indeed, working more on this issue I realized, that using
> FT_ADVANCE_FLAG_FAST_ONLY together with FT_LOAD_TARGET_LCD causes
> FT_Get_Advance to fail always.  Removing FT_ADVANCE_FLAG_FAST_ONLY,
> makes it work but very slow.
> 
> On the other hand, using FT_LOAD_NO_HINTING makes it to work really
> fast, but the computed width is not the same as the width of the
> rendered string with hinting enabled.
> 
> Which makes this function almost useless in the real world... :(

Well, caching is the solution.  Additionally, in case a font has a
hdmx table, and you are in non-ClearType mode, you can use the
pre-computed advance widths for a given PPEM value.

> Well I tested it with the following code (I simplified it in order
> to be more clear).  [...]

Uh, oh, please provide a C snippet, and tell us which font you are
using.  I apologize for not being able to work with ASM.


Werner

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-13 Thread John Found 
On Fri, 13 Mar 2015 09:45:57 +0100 (CET)
Werner LEMBERG  wrote:

> 
> > According to the FreeType documentation, the fastest way to compute
> > the width of some text string is to use FT_Get_Advance function that
> > returns the advance values without loading and rendering the glyphs.
> 
> See documentation of FT_ADVANCE_FLAG_FAST_ONLY for reasons why this
> can take a long time.

Indeed, working more on this issue I realized, that using 
FT_ADVANCE_FLAG_FAST_ONLY
together with FT_LOAD_TARGET_LCD causes FT_Get_Advance to fail always. 
Removing FT_ADVANCE_FLAG_FAST_ONLY, makes it work but very slow.

On the other hand, using FT_LOAD_NO_HINTING makes it to work really fast, 
but the computed width is not the same as the width of the rendered string
with hinting enabled.

Which makes this function almost useless in the real world... :(


> 
> Hmm.  Please provide a small snippet that demonstrates the problem.
> 

Well I tested it with the following code (I simplified it in order to be more 
clear).
The benchmark is to call the code 1000 times for a string 85 characters long. 
All text in the string is in English.

1. Using FT_Get_Advance: 

.char_loop:
stdcall DecodeUtf8, [esi]
jc  .finish ; invalid UTF-8

cinvoke FTC_CMapCache_Lookup, [FTCCMapCache], [.font], -1, eax
mov ebx, eax; glyph index

lea eax, [.advance]
cinvoke FT_Get_Advance, [.face], ebx, 0 and FT_ADVANCE_FLAG_FAST_ONLY 
or FT_LOAD_NO_HINTING, eax

testeax, eax
jnz .char_loop

mov eax, [.advance]
sar eax, 10 ; make it 26.6
add [.x], eax
jmp .char_loop

Benchmark approximately: 
  60ms   with FT_ADVANCE_FLAG_FAST_ONLY + FT_LOAD_NO_HINTING; Wrong width 
computed (3px wider)
  1600ms with FT_LOAD_TARGET_LCD only; Exact width computed.


2. Using the cache sub-system:

.char_loop:
stdcall DecodeUtf8, [esi]
jc  .finish

cinvoke FTC_CMapCache_Lookup, [FTCCMapCache], [.font], -1, eax
mov ebx, eax

lea ecx, [.type]
lea edx, [.glyph]
cinvoke FTC_ImageCache_Lookup, [FTCImageCache], ecx, ebx, edx, 0

testeax, eax
jnz .char_loop

mov ebx, [.glyph]

mov eax, [ebx+FT_GlyphRec.advance.x]
sar eax, 10; format 16.16 fixed decimal point.
add [.x], eax
jmp .char_loop


Benchmark approximately:

  65ms with the same flags used for rendering (FT_LOAD_TARGET_LCD + 
FT_LOAD_RENDER); Exact width computed.


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

2015-03-13 Thread Werner LEMBERG 

> According to the FreeType documentation, the fastest way to compute
> the width of some text string is to use FT_Get_Advance function that
> returns the advance values without loading and rendering the glyphs.

See documentation of FT_ADVANCE_FLAG_FAST_ONLY for reasons why this
can take a long time.

> But working on this task, I figured out, that using the cache
> sub-system and loading the whole images with "FTC_ImageCache_Lookup"
> and using the advance from the loaded image is faster than the above
> function.
> 
> And faster at least 5..10 times!

Hmm.  Please provide a small snippet that demonstrates the problem.


Werner

___
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype