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
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
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.
Post a reply to this message