What I think the parent post is missing is that breakthroughs in science don't immediately translate into breakthroughs in engineering and even less so into economically viable products.

While the algorithm presented here is sequential, this smells like it could be done in parallel.

In fact the "cum_aggs" stack is a prefix scan [2].

For the sum of values (and by extension also the average), if you have the input prefix scanned (which can be done in parallel) then you can answer any (yes any, dynamic size, not fixed size window) subslice reduction in constant time.

[0]: https://en.wikipedia.org/wiki/Fold_(higher-order_function) [1]: https://en.wikipedia.org/wiki/Convolution [2]: https://en.wikipedia.org/wiki/Prefix_sum

Relevant video by Kurzgesagt – In a Nutshell: https://www.youtube.com/watch?v=Mo1A45ShcMo

https://github.com/tejyash/delete-apple-intelligence-macos

For many the closed source nature of the compiler was a knock-out criterion. We will see if Mojo can gain traction now or if it has missed its window of opportunity.

Furthermore, the way the last mile distribution of power works is often underground (with the cables directly in the sand, no hose or tube around it) which makes it expensive to upgrade to handle a much higher peak consumption. Only lucky thing is that you mostly need AC when the sun is shining, thus local production via photovoltaic cells is a good solution that sidesteps the power grid problem.

Among the worst is the Birkeland-Eyde process, hot plasma by electric arcing, like it happens naturally during a thunderstorm. Even microwaving the air is more energy efficient. And amongst the most promising are transient non-equilibirum / cold plasma approaches using ns pulse generators.

Edit: So according to this video "Green Lightning" is indeed using the Birkeland-Eyde process. In other words, there is no way they even come close to their energy efficiency and yield claims. https://youtu.be/8TOnyAwJyvg?si=D9hat_XAfvuAAmpB&t=165

Hydro, wind and solar. Hydro is often even more important because it runs more steadily than the other two.

Geothermal and nuclear are neither fossil nor renewable, they are their own category.

Yes, they describe one variation of the angle based method to winding numbers by spanning a triangle fan from an arbitrarily chosen pivot point / vertex.

> if you want to do distance based anti-aliasing rather than supersampling

Particularly when it comes to rendering vector graphics I think of analytic anti-aliasing methods as somewhat cursed and prefer multisampling [0], at least for magnification. For minification mip-mapping remains the go to solution. However, if you only render 2D text on a 2D plane, which is typically overlap free, then these correctness issues don't matter.

> I don't see a straightforward way to apply this technique in a pixel shader that includes multiple curves per triangle

All modern vector renderers I know of avoid triangle rasterization entirely. Like I said, they typically do tiles (screen space partitioned into quads) in a compute shader instead of using the fixed functionality with a fragment / pixel shader. The reason is that nowadays compute is cheap and memory bandwidth is the bottle neck. Thus, it makes sense to load a bunch of overlapping geometry from global memory into workgroup shared memory, render all of it down to pixels in workgroup shared memory, and then only write these pixels back to the framebuffer in global memory.

> I feel like any attempt to do that will approach the complexity of Slug

A highly optimized implementation might very well, yes. Yet, handling the many cases of intersections of the path and the scanline won't be contributing to the complexity, which is what started this discussion.

> I would love to read more detailed information on that if you have it.

I implemented the outdated stencil buffer + triangle fan + implicit curves approach [1] if you want to take a look under the hood. The library is quite complex because it also handles the notoriously hard rational cubic bezier curves analytically, which Slug does not even attempt and just approximates. But the integral quadratic bezier curves are very simple and that is what is comparable to the scope Slug covers. It is just a few lines of code for the vertex shader [2], the fragment shader [3] and the vertex buffer setup [4].

Edit: You can even spin loop & blinn into a scanline method / hybrid: They give you the side of the curve your pixel is on [5], which is typically also the thing scanline methods are interested in. They compute the exact intersection location relative to the pixel, only to throw away most of the information and only keep the sign (side the pixel is on). So, that might be the easiest fragment shader vector renderer possible. Put it together in a shader toy [6] a while back.

[0]: https://news.ycombinator.com/item?id=46473247#46530503 [1]: https://github.com/Lichtso/contrast_renderer [2]: https://github.com/Lichtso/contrast_renderer/blob/main/src/s... [3]: https://github.com/Lichtso/contrast_renderer/blob/main/src/s... [4]: https://github.com/Lichtso/contrast_renderer/blob/main/src/f... [5]: https://news.ycombinator.com/item?id=45626037#45627274 [6]: https://www.shadertoy.com/view/fsXcDj

The original paper did assume no overlap yes. But that is not how anybody would implement it. For a long time one would use the stencil buffer with different operations depending on the front-face / back-face (this is where the paths rotation around the sample comes in and what makes this an angle based approach).

> which requires a complicated triangulation step. It can produce some nasty geometry in more complex cases.

Again, not how anybody would implement this. You can just stream the quadratic bezier curves unprocessed into the vertex shader, literally the simplest thing conceivable.

> With Slug, you can use only 1 quad per glyph if you want.

Nowadays one would probably implement loop & blinn in a tiled compute shader too (instead of using stencil buffers) to reduce memory bandwidth and over draw. That way you also get one quad per glaph, but without any of the geometry special casing that Slug does.

> It's the breakdown into different cases that _solves_ those issues, whereas your statement makes it sound like slug has _both_ the case complexity and the precision issues.

Correct, might have worded that badly. Still remains a trade off in a) which b) does not have.

a) The winding number of a point is the number of intersections of a scanline and a closed path.

b) The winding number around a point is the total angle subtended by the path at that point.

Slug uses approach a) and that comes with a lot of edge cases (see chart in the post) and numerical precision issues. The approach by loop & blinn uses b) and is thus simpler and more robust. Likewise the patent on that one expired too: https://news.ycombinator.com/item?id=47416736#47420450

https://x.com/ProgrammerLin/status/1342786223811698688 https://voxely.net/blog/

But I think the project was abandoned in 2021.

Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.

https://thisweekinbevy.com/ https://bevy.org/news/

Embrace the next challenge: Instead of roads on parabolic (Euclidean) geometry, have roads on elliptic (non-Euclidean) geometry, like the surface of a sphere. Plus, on a sphere every line is already a circular arc anyway (no matter if straight or bent, the difference is just the center, radius and normals). Thus, this system of circular arc segments really lends itself to such a space.

Little prince style micro planets with their own miniature infrastructure will always have a special place in my heart. Half a year ago I started with laying out the basics https://github.com/Lichtso/bevy_ellipsoid_billboard https://github.com/Lichtso/bevy_geodesic_grid but got distracted by fixing some engine bugs in Bevy along the way. That reminds me I have to update to the newest engine version ...

anyway you can find some of the roads on spheres stuff here: https://github.com/Lichtso/bevy_geodesic_grid/blob/main/src/... it can not only generate the extrusion mesh but also calculate how the mesh overlaps with a geodesic grid of triangular tiles on the surface.

In fact one could argue that this is a definition of an interesting system: It has to strike a balance between being completely ordered (which is boring) and being completely random (which is also boring).