Hacker News Reader

Comment by rasz_pl | Hacker News Reader

no subpixel rendering or hinting. Im confused - is there a problem with cpu rendered fonts that needs fixing? I didnt notice anything wrong last time I was reading schematics and datasheets on 4K monitor.

View on HN

> Im confused - is there a problem with cpu rendered fonts that needs fixing?

Performance. Even if an inefficient painting algorithm manages to paint at 60 FPS (which is very much not the case in, for example, common Web apps), improving its performance can free up the CPU to do more things and can reduce power consumption.

Think about it. If your GPU is sitting there idle, why not use it and free up the CPU to do other things? Today, most apps that aren't games are woefully underutilizing the GPU. Programs ideally should be utilizing all the silicon in your device while working so the work can be done faster and the hardware can enter low-power mode quicker.

On a modern PC games use a small fraction of the CPU and the GPU is the bottleneck. The only applications that really strain the CPU (i.e. all cores) are trivially parallelizable ones like transcoding, compilation, test suites, etc.

For games specifically I'd prefer more work done on CPU and free up the GPU, provided the communication overhead isn't too much and latency doesn't become a problem.

Low power is less of a problem than thermal limiting for compute intensive work. I see about 90% variation in test times on my laptop for unit tests, for example.

So overall I see more application for this in apps than games, and only then when the tradeoffs are right. It's not a simple call.

Games graphics engine guy here. I'm very happy to move text rendering from the CPU to the GPU. Done well it moves milliseconds of CPU work to tenths (or less) of milliseconds of GPU work.

Also, I care quite a bit about power draw because my customers on laptops and mobile are very sensitive to it. If my game is a battery hog, it doesn't get played as long or as often.

Sure, for games the tradeoffs may be different. For apps, though, we regularly see 1% GPU time, 99% CPU time. Even "GPU-accelerated" painting backends like Skia-GL can easily spend 90% of their time on the CPU--in the driver, issuing state changes, rasterizing fonts, building batches, creating display lists. It's not an exaggeration to say apps are desperate to find work that can be offloaded to the GPU.

Subpixel rendering isn't implemented in the demo but just requires running the calculations three times with 1/3 pixel offsets. It still would only need to read the texture data once. I didn't implement it in the demo because there's no way to ask the browser what the display's subpixel order is. If you're viewing it on an ipad and switch from portrait to landscape your subpixel order changes.

Hinting was necessary back before good antialiasing existed but I don't think many renderers use it now. This technique renders each glyph differently according to its subpixel position - completely the opposite approach to hinting, which snaps features of the glyph to integer positions on the pixel grid.

The demo that zooms in and out of a PDF is much faster than it would be with CPU rendering. When you zoom in and out in an existing PDF viewer, it takes much longer than 1/60 sec to re-rasterize the page.

The CPU takes a long time to rasterize fonts. It only seems fast because the glyphs are cached. If you need text drawn in so many different sizes, like in that demo, the cache is not as effective.

Don't know why you're getting downvoted. More performance is certainly always good, but without subpixel anti-aliasing the text will tend to look pretty crappy absent a ridiculously high resolution display.

Eh, nowadays you're probably rendering on a phone screen with a PenTile display and 300ppi, so the entire thing is moot.

Plus, every implementation of subpixel hinting I've seen (and I've seen them all, on all three major desktop platforms), produces absolutely disgusting colour fringing.

Just lay off the ClearType(tm) kool-aid and do normal anti-aliasing. We don't do colour-fringing anti-aliasing for any other geometric primitive, I see no reason to implement a font-specific approach that only works if the user is colour-blind.

Ridiculously high resolution displays are rapidly becoming the norm.

I assume you are thinking through it's implications for WebVR+servo?

I can see questioning the utility for current 2d applications but this is really critical speed when the large amount of translation and scaling of many pages in a 3d environment is the expectation.

The css3d "portal" solution for webgl doesn't seem like it can get us very far at all...

I'd use this today in my webvr/gl project if it was source complete.

This is useful for gaming or any other application where text is integrated into a GPU rendered 3D environment and may be subject to affine transformations.

Reply on news.ycombinator.com