Hacker News Reader

Comment by tenaciousDaniel | Hacker News Reader

Hi! This looks interesting, although I confess I'm very new to this area. I'm writing a programming language specifically for UI designers, and currently I'm building a naive implementation in html5 canvas. I know very little about low-level rendering - just really know how to use drawing API's like canvas and Quartz 2D.

With that being said, I'm looking to delve deeper into this subject. Do you have any recommendations on where to start? Whenever I look beyond simple drawing API's, the focus seems to be entirely on 3D rendering (which is interesting but not my main focus right now).

View on HN

It's a good question, as honestly the knowledge for 2D graphics is pretty arcane, as opposed to 3D being so widely taught. I actually started a github repo for a book on 2d graphics but have no idea whether I'll actually finish it.

In the meantime, antigrain.com is one good (if old) source. The original PostScript "red book" was extremely influential in its time (it's where I learned a lot of this stuff) but is quite dated now. Best of luck, and I'm also happy to field requests for more specific areas. For example, for color theory (an important aspect of 2D graphics!), handprint.com is quite a remarkable resource.

Thanks!

> knowledge for 2D graphics is pretty arcane

such an unfortunate state of affairs!

i am currently learning how to render graphics using the GPU on my mac using apple metal. what i am getting is that the GPU has been optimized for 3D rendering?! GPUs make no provision or easy way for rendering 2D graphics?

it makes no sense to me... that's where you start...

now this may be a dimb question, but why would you start there?

as far as i understand, 2d and 3d have literally zero to do with each other in how they are rendered. one is a bunch of triangles. the other is lines, curves, thickness, gradients, and fonts (which are essentially little programs)

that's not a dumb question! it's my own fault. i only have knowledge of 2D graphics.

> the other is lines, curves, thickness, gradients, and fonts

You can reduce all these to drawing triangles.

Doing that reduction is surprisingly difficult, and usually a serial algorithm that runs on the CPU, and a naive approach is a resulting triangle set is not efficient to a GPU, but that's what toolkits like cairo, Direct2D, nanovg do.

Raph is describing an architecture where path evaluation happens on the GPU, without being baked to triangles.

> You can reduce all these to drawing triangles.

You can, people have tried this, and it sucks. The main problem is that the conversion of Bézier paths to triangles is a hard problem with lots of conditional branching. Even when you do it, there is the other problem of rendering triangles with really good antialiasing, MSAA forces a compromise between performance and quality. By contrast, piet-gpu does an exact-area calculation for antialiasing.

So it's not a question of whether you can do it, but whether it works well, and approaches like piet-gpu absolutely stomp triangles.

> there is the other problem of rendering triangles with really good antialiasing

Easier than you think. Here's couple lines of pixel shader that does that, with really good antialiasing and without MSAA:

https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/Sha...

yes, you can draw 2d in 3d space. this thread however is about 3d being built on top of 2d. not 2d being built on top of 3d.

I remember asking a similar question on HN a while back. The response was that 2D graphics, UIs in particular, are mostly computed on the CPU. I have no idea why this is the case, though.

See this blog, it explains it pretty well imho: https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...

And: historically they've been computed mostly on CPU, but I think it's time for that to change.

> And: historically they've been computed mostly on CPU, but I think it's time for that to change.

It would be great to wait a bit for OS & GPU power management to evolve before biting the bullet on that. My laptop goes from 6 to 2.something hours of battery as soon as I have a GL context opening somewhere, likely because it seems to power on its discrete GPU automatically in that case.

Don't fool yourself, they won't do anything until most of the browser/apps do it. Then they will fix it to sell "longer" battery life.

With most dual-GPU machines you do get a choice whether to power on the discrete GPU or not. It's even supported on GNOME/Wayland as of late.

This is changing. I've been doing power measurements as well (just didn't make the cut of this blog post), and the 1060 is surprisingly power-efficient in its low frequency modes. It's also generally the case that the GPU is always active in its role running the compositor.

> and the 1060 is surprisingly power-efficient in its low frequency modes.

maybe ? the computer on which this happens is a 1070. But please be aware that series 10 are a very small percentage of people. The average laptop of non-tech people around me is easily 8 years old, often on their 2nd or 3rd battery... and these people won't be able to complain easily to anyone when their new battery's life suddenly is halved because of $SOFTWARE.

Both macOS and Windows have ways for applications to specify whether they want to prefer a discrete gpu or integrated.

During the late 1990s and early 2000s it was a lot more common for GPUs to provide 2D acceleration, and GUIs were drawn using those primitives. I remember the switch to CPU rendering happening, and the subsequent removal of 2D acceleration from GPUs, but I don't remember why.

At any rate, the 2D graphics we expect now are a lot more complex than the unantialiased lines, blits, and fills of old.

If you need portable results pixel to pixel on various platforms then CPU based rendering is more straightforward than using the GPU.

The various libraries such as freetype for font rastrization only works on CPU.

Plenty of work should be done to research and implementation is left to be done in order to use the GPU more widely.

This is an interesting and subtle point about doing "software on GPU compute." You are in complete control over what gets computed, and are not at the mercy of the hardware's fixed function pipeline for stuff like rasterization rules and sampling patterns for antialiasing. So I think portable results pixel to pixel are in fact viable.

Of course CPU rendering is always more straightforward than GPU, the higher performance comes at a significant cost in complexity.

I've done a fair bit of 2d graphics work (written a rasterizer, etc). Honestly it's because it's

  1) tricky to shoehorn 2D graphics onto the APIs that GPUs provide and 
  2) really not needed.  I can easily render eg: a world map with hundreds of thousands of lines at hundreds of frames/second with one core.

Please don’t use preformatted text to write lists. It’s a pain. Just leave a blank line between the items so that each is a paragraph.

Haiku OS AppServer (the screen rendering component, similar to Unix X11) is a full GUI system implemented with AntiGrain Geometry as the renderer.

I think that blend2d (https://blend2d.com/) is a worthy successor to AGG, and it's under active development.

Thank you for the link. It was a great reading. But I just want to point out that Blender2D is a software renderer.

So is/was AGG

I recommend the blog of the OP, so many gems

Reply on news.ycombinator.com