Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

91–100 of 230 posts

Re: Memory safety for web fonts

#91

Post by dsp_person »

jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

Better comparison would be fresh code in Rust vs fresh code in C. Re-writing in both languages following best practices testing and fuzzing. A big difference vs comparing to legacy C code that is trying to be maintained by throwing 0.25 google engineers at it to fix an ongoing stream of fuzzing issues.

Re: Memory safety for web fonts

#92

Post by acdha »

hombre_fatal wrote: post #76
graemep wrote: post #67

Earlier quoted context omitted.

There would be far fewer bugs if people actually stick to writing code like that. I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long. I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.

On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.

Maybe, but it usually has the opposite effect. If you have well-designed and named functions the indirection is a feature since it reduces the amount of context you need to remember and gives you a visible contract instead of having to reason about a large block of code.

Re: Memory safety for web fonts

#93

Post by grishka »

cosmic_cheese wrote: post #53
wkat4242 wrote: post #47

Earlier quoted context omitted.

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

macOS dropped it a few years ago, primarily because there are no Macs with non-HiDPI displays any more (reducing benefit of subpixel AA) and to improve uniformity with iOS apps running on macOS via Catalyst (iOS has never supported subpixel AA, since it doesn’t play nice with frequently adjusted orientations). Windows I believe still uses RGB subpixel AA, because OLED monitor users still need to tweak ClearType setti…

> because there are no Macs with non-HiDPI displays any more

That is not true. Apple still sells Macs that don't come with a screen, namely Mac Mini, Mac Studio, and Mac Pro. People use these with non-HiDPI monitors they already own all the time.

Re: Memory safety for web fonts

#94

Post by tadfisher »

kiicia wrote: post #46
SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

For me, being old time user, (ab)using any subpixel layouts for text rendering and antialiasing is counterproductive and (especially with current pixel densities, but also in general) introduces much more issues that it actually ever solved “Whole pixel/grayscale antialiasing” should be enough and then specialized display controller would handle the rest

Agreed, but layouts such as Pentile don't actually have all three subpixel components in a logical pixel, so you'll still get artifacts even with grayscale AA. You can compensate for this by masking those missing components.

https://github.com/snowie2000/mactype/issues/932

Re: Memory safety for web fonts

#95

Post by kortilla »

kevingadd wrote: post #48
kiicia wrote: post #41

Earlier quoted context omitted.

The real issue is the effort required to rewrite everything without introducing new bugs resulting from a misunderstanding of the original code

New (likely aesthetic only) bugs in font rendering are probably considered preferable to existing security vulnerabilities, I would hope.

“Aesthetic only” bugs for a project entirely for aesthetics can easily kill the usage of it.

Nobody cares about a CVE-free rendering library if it can’t render things correctly.

Re: Memory safety for web fonts

#96

Post by pornel »

tsuru wrote: post #5

It looks like there is an extern C interface... I wonder if it is everything necessary for someone to use it via FFI.

They just need to rewrite the rest of Chrome to use the native RustRust interface.

(in reality Google is investing a lot of effort into automating the FFI layer to make it safer and less tedious)

Re: Memory safety for web fonts

#97

Post by layer8 »

ghusbands wrote: post #90
wkat4242 wrote: post #47

Earlier quoted context omitted.

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

To be clear: Windows still does subpixel rendering, and the wizard is still there. The wizard has not actually worked properly for at least a decade at this point, and subpixel rendering is always enabled, unless you use hacks or third-party programs.

DirectWrite doesn’t apply subpixel anti-aliasing by default [0], and an increasing number of applications use it, including Microsoft Office since 2013. One reason is the tablet mode starting with Windows 8, because subpixel ClearType only works in one orientation. Nowadays non-uniform subpixel layouts like OLED panels use are another reason.

[0] https://en.wikipedia.org/wiki/ClearType#ClearType_in_DirectW...

Re: Memory safety for web fonts

#98

Post by perching_aix »

wkat4242 wrote: post #47
SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

It didn't. Some parts of the UI are using grayscale AA, some are on subpixel AA. And sometimes it's just a blur, to keep things fun I guess.

Pretty sure phones do grayscale AA.

Re: Memory safety for web fonts

#99

Post by crazysim »

jorvi wrote: post #83
pradn wrote: post #73

Earlier quoted context omitted.

Yes, a SWE-year is a common unit of cost. And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB. This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea. I personally have use…

Note that this can lead to horrid economics for the user. An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU. It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.

It also saved licensing costs to MPEG-LA too I guess.

Re: Memory safety for web fonts

#100

Post by rs186 »

jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

That perspective was never correct to begin with. Along with laughable comments I have seen like "memory safety is easy. Memory related bugs are created by bad programmers".

See comments under this video: https://youtu.be/gG4BJ23BFBE

We are all humans, and humans make mistakes. The obvious way to avoid mistakes is to formalize "correct code" and get code chekced by machines, and in this context, let the compiler guarantee the correctness. Anything else will never be as effective.

Post reply on HN