mfabbri77

Miter join (Safari) VS round join (Chrome)

The point was to answer the question: "Can every piece of software be viewed as a permutation of software that has already been developed?" In my opinion, an email client is a more favorable example than a 3D engine. In fields where it is necessary to differentiate, improve, or innovate at the algorithmic level, where research and development play a fundamental role, it is not simply a matter of permuting software or leveraging existing software components by simply assembling them more effectively.

In my experience, the further you move away from the user and toward the hardware and fundamental theoretical algorithms, the less true this becomes.

This is very true for an email client, but very untrue for an innovative 3D rendering engine technology (just an example).

Yes. This happens because the training data contains countless SotA "to-do" apps. This argument does not scale well to other types of software.

Back in 80/90 we used to call it "demoscene".

What if someone doesn't declare that it has been reimplemented using an LLM? Isn't it enough to simply declare that you have reimplemented the software without using an LLM? Good luck proving that in court...

One thing is certain, however: copyleft licenses will disappear: If I can't control the redistribution of my code (through a GPL or similar license), I choose to develop it in closed source.

OpenVG is just an API by Kronos group, that was never implemented by hardware vendors on desktop graphic cards (it was specifically created for mobiles, as OpenGL|ES).

Btw, there exists several implementations, with pure CPU rendering (like AmanithVG SRE) and others with GPU backends.

If the AI product is recognised as "derivative work" of a GPL-compliant project, then it must itself be licensed under the GPL. Otherwise, it can be licensed under any other license (including closed source/proprietary binary licenses). This last option is what threatens to kill open source: an author no longer has control over their project. This might work for permissive licenses, but for GPL/AGPL and similar licenses, it's precisely the main reason they exist: to prevent the code from being taken, modified, and treated as closed source (including possible use as part of commercial products or Sass).

This has the potential to kill open source, or at least the most restrictive licenses (GPL, AGPL, ...): if a license no longer protects software from unwanted use, the only possible strategy is to make the development closed source.

This issue can be resolved on the European side by effectively making the transfer of EU->US data illegal and, if detected, nationalizing the entire EU subsidiary of the US company. Would this trigger a US-EU war? Certainly, but only the blind cannot see that relations are no longer those between two allies.

I don't know how common it is in fonts, but for generic 2D vector graphics, problems arise from the management of self-intersections, i.e., the pixels where they fall. With an SDF rasterizer, how do you handle the pixel where two Bezier curves intersect in a fish-shaped path? For this reason, more conventional rasterizers with multisampling are often used, or rasterizers that calculate pixel coverage analytically, also finding intersections (sweepline, Bentley-Ottmann).

I'm always interested in new 2D vector rendering algorithms, so if you make a blog post explaining your approach, with enough detail, I'd be happy to read it!

At what order of magnitude in the number of elements to be sorted (I'm thinking to the overhead of the GPU setup cost) is the break-even point reached, compared to a pure CPU sort?

You have to look for "stroking": there are several ways to do it, in CPU you usually first perform a piecewise linear approximation of the curve, then offset each segment along the normals, add the caps, get a polygon and draw it.