On 2/3/19 4:04 AM, clipka wrote:
> 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.
> 
> Actually, wading through the old code for unrelated reasons, I just 
> noticed that this isn't true: The old `text` primitive has actually been 
> a CSG union all along, with one child per character.

Hmm. Not my recollection or experience. I was focused on inside tests if 
those were perhaps done differently than intersections. The glyph loop 
range testing I added helped regular intersection performance too, but 
less.

Anyway. I'll keep what you saw in mind. Possible the code work I did was 
pointless, and the performance gains seen false, for reasons of 
self-foolery.

I'm maintaining my text branch with the thought the new text object 
might also be too slow for what I want. Means, if motivated, I can again 
do performance comparisons to the 'old' text object as well as your new 
one off master, but, I probably won't so long as the new is fast enough.

Bill P.

Post a reply to this message