Live data from Hacker News

Swift at Apple: Migrating the TrueType hinting interpreter

swift.org

91–100 of 139 posts

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#91

As much as I enjoyed Swift, one can only wonder what the world would look like if they had gone with Rust as their default language instead.

Apple has a runtime system that looks a lot like smalltalk. Everything at that layer is dynamic. They needed a language that could seamlessly interact with that system.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#92
post #64

Beware: As of a few months ago, when I tried to use the lifetime features shown off in this post, I ran into constant compiler crashes with very simple programs, until I gave up and wrote off the features as unusable. This happened on both stable and nightly compilers. I guess they work well enough for this TrueType interpreter, but I suspect they’re using a narrow subset of what the features are supposed to support.…

Average swift experience

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#93

> Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary. It does feel like a compile…

I've always wondered if JS engines could rewrite those array functions at compile time, like this: https://github.com/SomeRanDev/Haxe-MagicArrayTools

Though, it probably wouldn't work if user code modified the Array prototype.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#94
post #90

"we used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 without any loss of code coverage" Did they need a fuzzer for that? They could've render them all and see what's exercised?

Its a set cover problem, and is NP-hard. 4100 of something probably runs nicely in your laptop in a reasonable amount of time.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#95
post #74

Earlier quoted context omitted.

It’s very common for the people who got their last monitor 8 years ago.

It's still the most common resolution for people using desktop monitors today, according to: https://gs.statcounter.com/screen-resolution-stats/desktop/w...

Also for gaming too: https://store.steampowered.com/hwsurvey/

1920 x 1080 51.89%

2560 x 1440 21.20%

3840 x 2160 5.00%

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#96
post #2

During the State of Platform keynote, on the subject of Swift adoption across macOS, several examples were given, not only TrueType engine. RIS is happening across all OS levels, if the keynote is to be believed.

Alexandre Colucci has published a series of articles analysing the use of Swift in iOS and macOS by Apple here:

https://blog.timac.org/categories/reverse-engineering/

And frequently discussed on Hacker News:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#97
post #56

Earlier quoted context omitted.

s/better/blurrier/

Life without retina displays is possible, but pointless.

Lower DPI is quite okay with good font rendering (FreeType, slight hinting, subpixel rendering). I have both kinds of devices.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#98

I'm surprised the code has visible LLM smells. Though, I shouldn't be surprised. I hope the important bits are still human-controlled (and the same for Apple's many operating systems that absolutely deserve to remain stable and understood).

I assure you, every inch of the interpreter code has been stared at by humans, a lot. TBH even the assembly generated by it has.

All 150 kloc in six months by two people? Actually, it sounds like way too much code for the task unless 70+% of it is tests.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#99

What's funny is from 2023 (I think), macOS just draws the UI unhinted. You have a 1080p display and you don't want to see the letters in the UI blurred to death? Tough luck, 1080p is incompatible with macOS, everybody needs "retina", and nobody cares that Windows and all Linux DEs look on 1080p just fine. It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.

Retina displays were introduced more than a decade ago. Why should Apple still support outdated technology after such a long time?

If you work with text and fine UI elements, do yourself a favour and get proper tools for the job. Get an ergonomic mouse and a good keyboard while you're at it. In every other field professionals use high quality tools to do their jobs, IT shouldn't be any different.

A plumber has equipment worth tens of thousands of dollars, while IT professionals think it's outrageous to pay a few hundred for equipment which is undeniably an improvement.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#100
post #95

Earlier quoted context omitted.

It's still the most common resolution for people using desktop monitors today, according to: https://gs.statcounter.com/screen-resolution-stats/desktop/w...

Also for gaming too: https://store.steampowered.com/hwsurvey/ 1920 x 1080 51.89% 2560 x 1440 21.20% 3840 x 2160 5.00%

OS font rendering doesn't matter for gaming.
Post reply on HN