Am 17.01.2019 um 15:05 schrieb William F Pokorny:

>> - Performance has degraded a bit, but I'm willing to accept this for 
>> the sake of extended functionality and easier maintenance.
> 
> Hmm, I'm surprised some by this. Are your test character strings really 
> short? In the existing text shape code all the characters ended up more 
> or less as one huge glyph as you know. As the string to the text shape 
> got large, performance slowed substantially. Your implementing 
> internally as a union of prisms should address this shortcoming well - 
> providing a lot of room for other code to slow without overall impact. 
> Wonder... Is the prism object a lot slower than the text object was? 
> (I've never compared)

My strings are roundabout one or two dozen characters.

My first guess was that it was caused by 3rd order vs. 2nd order 
splines, but that doesn't seem to make much of a difference.

Another potential cause for slowdown could be rooted in prism being able 
to support conic sweeps.

My current guess however is that there's some "poor man's bounding" 
hidden in the TrueType code that the prism doesn't have.

What I can say is that the same text strings composed into a single 
prism gave abysmal performance.

What I also can say is that my performance comparisons were only cursory.


>> - POV-Ray v3.7 (haven't checked whether this has been fixed already) 
> 
> It is fixed in the current 3.8 master. You picked up - or made 
> independently - a change quite like one Jérôme made in hgpovray.

Yeah, found text to that effect in the changelog, so it must be true ;)


>> - (*) For normal TrueType fonts, that is. Based on the FreeType 
>> documentation, I totally expect the new implementation to get this 
>> wrong, and/or to mess up the "holes" (e.g. in characters like `o`), 
>> with /some/ font file formats or even individual fonts. Please keep 
>> your eyes peeled, I'm keen to get my hands on any such font specimens.
> 
> I have somewhere a crude test set up / scene collection I created when I 
> did my text shape hacks. I'll put it on my list to run those.
> 
> Plus, IIRC, I saw font sites offering fonts in multiple formats. Might 
> be we can turn up problems with holes / overlaps or whatever by running 
> such format sets and comparing resultant images. I now have a pretty 
> good semi-automated testing framework for that sort of scene to sceen 
> image testing so shouldn't take too much to get something going - 
> provided I'm right about the availability of fonts in multiple formats.

If you would like to pick up that glove some time in the near future, 
I'd very much appreciate it.

Right now, I have found one font where the surface normal orientation is 
broken for at least one character, namely the closing square bracket 
("]") in the "Arial Black" font. I blame FreeType, with the mechanism 
being that the font defines that glyph by scaled reference to the 
opening square bracket glyph ("["), mirroring it horizontally (and thus 
messing up control point order).

Post a reply to this message