Also: The use of linked fonts (i.e. the TTCFont with a TTFontDescription) is currently rather slow regarding #hasGlyphOf:. I am working on it.

Best, Marcel Am 17.02.2022 11:59:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Also: Please increase your Glyph cache first before making any experiments. See preference TTCFont glyphCacheSize. The interference between cache invalidation and you removing that primitive might be leading to wrong conclusions... :-)

Best, Marcel Am 17.02.2022 11:58:07 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Tony --

I will look into this. The primitive is not dead for me... Fallback code seems a little bit slower...

why is it re-layouting when I just change the TransformMorph's offset??

It is not. The CompositionScanner does the layouting. The DisplayScanner does the display. Both are of superclass "CharacterScanner". Both need that primitive. I suppose.

I will check is along with my current work on TrueType fonts and related caches.

Best, Marcel Am 17.02.2022 10:07:17 schrieb Tony Garnock-Jones tonyg@leastfixedpoint.com: Hi all,

Commenting out "" in CharacterScanner>>primScanCharactersFrom:to:in:rightX:stopConditions:kern: immediately and dramatically improves the performance of scrolling anything truetype-font-ish on my very slow arm64 cellphone.

It's still not *fast* (why is it re-layouting when I just change the TransformMorph's offset??) but it's faster than it was before, which was "lock up the entire UI for ten seconds while thinking about failing primitive 103"-speed.

Interestingly, fast x86_64 machines aren't immune either! Running a tally in the same image on my x86_64 pc with a modern VM, and doing the same scrolly thing, showed primitives to be taking a significant chunk of time. Commenting out "" there immediately eliminated a lot of wasted CPU usage, though the machine is so fast it's not easy to notice the improvement at squishy meatbody sensory refresh rates.

So, should I commit a change that comments out "" for good? I don't see a downside! Is there one?

Cheers, Tony

Hi Tony --

Please give me 1 more day. I am almost finished refactoring TTFontReader. :-)

Currently, use the FontImporterTool. Or use this interface to try out a font without installing it into Squeak:

fontFile := '/Users/ecgade/Downloads/Santakku/SantakkuM.ttf'. fontReader := TTFontReader parseFileNamed: fontFile. myCoolFont := TTCFont new ttcDescription: fontReader first; pointSize: 36.0; yourself. myCoolFont browseAllGlyphs.

Best, Marcel Am 17.02.2022 12:08:23 schrieb Tony Garnock-Jones tonyg@leastfixedpoint.com: Hi Marcel,

On 2/17/22 12:00, Marcel Taeumel wrote:

Also: The use of linked fonts (i.e. the TTCFont with a TTFontDescription) is currently rather slow regarding #hasGlyphOf:. I am working on it.

This reminds me: I'm currently loading my font by some adhoc method I discovered by trying things until they seemed to work. This seems likely to be suboptimal.

What's the recommended way to load a .ttf into the image (so that everything is self contained in the image and fast to use)?

Cheers, Tony

PS. this is how I'm loading the font:

| description | description := TTFontDescription addFromTTFile: 'fonts/from-github/Roboto-Regular.ttf'. TTCFont newTextStyleFromTT: description first. TTCFont registerAll.

"Note in particular that I had to use 'description first' - is that a bug? Previously, using 'description' was the right thing to do, and TTCFont class >> newTextStyleFromTTFile:, which I was using previously, still expects to be able to use 'description'..."

Hi Tony --

The changes are live. :-) Here is how you can install a font:

TTCFont class >> #installFromFileNames: TTCFont class >> #uninstallFontNames:

There is commentary in both methods. Let me know if this helps. Maybe also take a look at the class side of TTFontFileHandle.

Best, Marcel Am 17.02.2022 12:26:35 schrieb Tony Garnock-Jones tonyg@leastfixedpoint.com: On 2/17/22 12:20, Marcel Taeumel wrote:

Please give me 1 more day. I am almost finished refactoring TTFontReader. :-)

Will do!

This isn't urgent - I have a solution that's working well enough for now.

Currently, use the FontImporterTool. Or use this interface to try out a font without installing it into Squeak:

I need to script it, so the FontImporterTool is out. And I need to load it into the image.

For now, I'm happy to wait for the finished product :-)

Cheers, Tony

Hi Marcel,

On 3/1/22 17:57, Marcel Taeumel wrote:

TTCFont class >> #installFromFileNames: TTCFont class >> #uninstallFontNames:

Does this install a reference to a font file, or does it load the font data into the image, making the font file no longer needed?

I need the latter, but it looks like the former might be going on, so I thought I'd check.

(I'm not stuck, though, because my old procedure of the following still works OK:

description := TTFontDescription addFromTTFile: 'fonts/from-github/Roboto-Regular.ttf'. TTCFont newTextStyleFromTT: description first. TTCFont registerAll.

)

Cheers, Tony

On 3/9/22 14:48, Marcel Taeumel wrote:

Just call TTCFont >> #becomeLocalFont to be sure. :-) Yes, being remote is the default.

Thank you! I'll try that.

Cheers, Tony

Hi Tony --

I just checked. Primitive 103 does not fail for me. I added this:

<primitive: 103> Smalltalk at: #ScanFail put: (Smalltalk at: #ScanFail) + 1. ^self basicScanByteCharactersFrom: startIndex to: stopIndex in: sourceString rightX: rightX

And #ScanFail keeps being 0. The primitive 103 works here. :-) Currently 32-bit OSVM on Windows 10.

Best, Marcel Am 17.02.2022 12:10:16 schrieb Tony Garnock-Jones tonyg@leastfixedpoint.com: On 2/17/22 11:59, Marcel Taeumel wrote:

Also: Please increase your Glyph cache first before making any experiments. See preference TTCFont glyphCacheSize. The interference between cache invalidation and you removing that primitive might be leading to wrong conclusions... :-)

Oh, that's very interesting!

So first of all let me clarify that I was seeing multiple-second delays with primitive 103 enabled, but mere multi-hundred-millisecond delays with it disabled. Does the primitive touch the cache?

I'll explore different settings.

Is it recommended to increase the cache size after importing a new font, or is it something that should maybe be a bit larger by default anyway?

Cheers, Tony

Nevermind. The primitive 103 fails for TTCFont (200%) but not for StrikeFont (125%). Yet, the only performance issues I noticed where from a too small GlyphCacheSize.

Best, Marcel Am 17.02.2022 12:27:54 schrieb Tony Garnock-Jones tonyg@leastfixedpoint.com: On 2/17/22 12:15, Marcel Taeumel wrote:

I just checked. Primitive 103 does not fail for me. I added this:

Interesting. I didn't actually *check* that it was failing, I just assumed based on the drastic speedup I got by commenting it out!

I'll put it back in, but it's quite possible that my other changes to avoid gratuitous relayouting will make it no longer very important. Hmm. We'll see.

Tony

Hi Tony, hi all --

Note that the performance of TrueType text composition was improved with Squeak 6.0. We do not try to use primitive 103 in that case anymore.

Best, Marcel Am 17.02.2022 12:44:18 schrieb Tony Garnock-Jones tonyg@leastfixedpoint.com: On 2/17/22 12:33, Marcel Taeumel wrote:

Nevermind. The primitive 103 fails for TTCFont (200%) but not for StrikeFont (125%). Yet, the only performance issues I noticed where from a too small GlyphCacheSize.

Yeah, I'm not seeing a performance difference either now I've reenabled it. I guess it's still there, but that code path isn't being stressed anymore, so it's not noticeable.

Cheers, Tony

Hi Dave, hi all --

Primitve 103 has still a great performance advantage for StrikeFonts, which are currently used at 100%, 125%, and 150% scale factor. Let's not remove it.

Best, Marcel Am 07.07.2022 15:12:11 schrieb David T. Lewis lewis@mail.msen.com: A note regarding the subject line of this message:

"Dead primitive ... Let's get rid of it"

If this means "stop using primitive nnn in the image", then fine. If it means "remove primitive nnn from the VM", it is not fine at all. The reason is that VMs need to be able to support older images that depend on that numbered primitive assignment.

This by the way is that reason that the use of numbered primitives is a Very Bad Thing. I wish we could come up with a way to stop doing that. Maybe there could be some way to generate a numbered primitive table dynamically for the jit without hard coding the assignments in initializePrimitiveTable in the VM?

Dave

On Thu, Jul 07, 2022 at 02:33:24PM +0200, Marcel Taeumel wrote:

Hi Tony, hi all --

Note that the performance of TrueType text composition was improved with Squeak 6.0. We do not try to use primitive 103 in that case anymore.

Best, Marcel Am 17.02.2022 12:44:18 schrieb Tony Garnock-Jones : On 2/17/22 12:33, Marcel Taeumel wrote:

...

Nevermind. The primitive 103 fails for TTCFont (200%) but not for StrikeFont (125%). Yet, the only performance issues I noticed where from a too small GlyphCacheSize.

Yeah, I'm not seeing a performance difference either now I've reenabled it. I guess it's still there, but that code path isn't being stressed anymore, so it's not noticeable.

Cheers, Tony