vg_head

Good looking! I didn't get to watch the video or look at docs in depth, but do the results trace back to the location of the answers in a document? Let's say it finds an answer in a PDF, and I'd like to know where in that PDF the citation is. Is that possible or intended?

Of course it's not optimal, it was simply a pragmatic trade-off. This wasn't the only case with lots of paths, and the divide-and-conquer approach improved the runtime performance substantially on all of them.

What you are proposing is valid, however the “checking each intersection” part is far from a simple one. It's difficult enough with polygons only, but the input can have Bézier curves too. I highly doubt everything would amount to Log(n) - after all Skia already does something similar to what you're saying, unless I'm misunderstanding.

I didn't get to simplify the code further unfortunately. I could have, but I was running very tight on time with other things. In fact the running-in-production-version is even worse than what I've posted, I just went with what worked fast on the first try and moved on to something else immediately. But it can absolutely be improved further!

> This seem like more of a surprise to the author than it was for me.

The bigger surprise for me was that the path builder is slower than doing divide and conquer, given that it's optimized for doing union on everything.

> Sometimes it would help to read a book or consult someone more knowledgeable though.

I'd be happy to receive suggestions!

I'm curious if there's overlap between this and P System: https://en.m.wikipedia.org/wiki/P_system

Very interesting. Honestly I don't know much about hinting, but I suspect the whole shaping stack that Slug supports:

> kerning, ligature replacement, combining diacritical mark placement, and character composition. Slug also supports a number of OpenType features that include stylistic alternates, small caps, oldstyle figures, subscripts, superscripts, case-sensitive punctuation, and fractions.

Probably still uses the CPU.

> Explain to me exactly why, other than 'I guess someone already implemented some kind of basic version of it' that you would have to have custom CPU code rendering glyphs instead of a shader rendering SDF's like literally everyone does with shaders already?

Shaping is different compared to rendering glyphs themselves. SDF renderers (and other GPU text renderers like Slug) still do shaping on the CPU, not in shaders. Maybe some experiments have been done in this area, but I doubt anyone shapes text directly in the GPU in practice.

Think of it like a function that takes text as input, and returns positions as output. Shaders don't really know anything about text. Sure you could probably implement it if you wanted to, but why would you? I think it would add complexity for no benefit (not even performance).

It's more about the nature of the problem, not that you can't do it in shaders. After all, I think you can do pretty much anything in shaders if you try hard enough.

Even if you already have a GPU renderer for glyphs and any other vector data, you still want to know where to actually position the glyphs. And since this is highly dependent on the text itself and your application state (that lies on the CPU), it would actually be pretty difficult to do it directly on the GPU. The shader that you would want should emit positions, but the code to do that won't be easily ported to the GPU. Working with text is not really what shaders are meant for.

One other thing that is a bit weird about SVG is how some parts don't feel tightly integrated. For example, paths and SMIL events have their own syntax. And a lot of APIs related to them seem to be either abandoned, deprecated, or just hard to find. There's also SVG2 which is confusing, as it seems like no browser will ever implement it fully.

That being said, SVG allows you to create quite beautiful and complex effects with relatively little code.

I've been following VGC for some time now, and I definitely think it's the coolest project of its kind right now! I sincerely hope it will be widely used.

I am too young to have lived through that era, but it seems to me like tweening hints were all integrated in the editing UI? That is of course much more useful. But the scope of my post was not at all to do something better than Flash, or to integrate a full editor. It's just an explanation for one way to achieve it, leveraging what SMIL already offers.

I haven't looked too in depth into it, but it looks closer to what I described? It doesn’t look like the method the other commenter was describing.

Also, keep in mind that I did not mean to implement something better than what Flash did. It's merely an extension to the kind of morphing the browsers already offer.

Always open to suggestions! I don't claim this to be any kind of novel method, or even a "good method". It's just an explanation of one way to do it, which is (IMO) relatively easy to understand, and implement.

When researching about this, I didn’t find a lot of writing. Macromedia definitely had this a long time ago, but I don't think you can look up how it was implemented. Not to my knowledge, at least.

Do you have an example of the algorithm you describe? Or a more detailed explanation? I don't quite get how it would work from what you've described.

Yes, at least that would be a great start for me.

This is exactly the kind of tool I would want as well. I was surprised nothing like this exists already.

I've just finished working on a dead simple OCR tool: https://txtfromimg.com

I know there are plenty of alternatives, but I personally benefit a lot more from a dead simple web page, that does everything locally. It also helps with burnout, I like building very simple, but useful things (at least for myself).

I also have plans for a more serious project though. For a long time now I've been writing down what I would want from a ShaderToy-like website but for SVGs. I feel like there's a lot of potential in making it easy to create and reuse amazing animations with very little code.

I've also seen a lot of people praise the React + SVG combo and I can see why. I'd personally love an environment that I could just spin up instantly, create paths interactively, then create some effects quickly, and then use them wherever I want.

Thank you! Looking forward to your research.

Nice project! I see the tool can already handle polylines, so in theory you should be able to add support for Bézier curves and arcs by converting them to polylines. But of course, the devil is usually in the details. I hope it works out.

There's also Software-Transactional Memory in which deadlocks are pretty much impossible. Though it only really works in languages that can properly track side effects, like Haskell's monads.

My experience with parsing undocumented binary formats is with Skia's skp files. Unfortunately they don’t publish any docs regarding the format. Instead I relied on their source code (which is very convoluted), and in that process I discovered two tools which proved pretty useful:

- Kaitai [1], which takes as input a YAML file and can parse binary files based on it (and even generate parsers).

- ImHex [2], which has a pattern language [3] which allows parsing, and it seems more powerful than what Kaitai offers. I stumbled upon some limitations with it but it was still useful.

[1]: https://kaitai.io/

[2]: https://github.com/WerWolv/ImHex

[3]: https://docs.werwolv.net/pattern-language/

I am curious as well. Unfortunately there's not a lot of info out there. It's a bit weird to me that the repo says it's a CPU renderer, but most of the code seems to use the GPU (with rust-wgpu).

With so little documentation it's hard to know exactly how it works, but I am curious if its architecture is similar to: https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fas...

I am really interested in your research related to vector graphics!

Paper is from 2019, and the original title is "Hierarchical Rasterization of Curved Primitives for Vector Graphics Rendering on the GPU", I had to adapt the title and omit the year because it would have been too long

Indeed, most techniques that target the GPU have no response to stroking, they recommend generating paths beforehand so that it looks like it's stroked.

And yes, the number of triangles doesn't really make a difference in general, but in Slug's paper they say:

"At small font sizes, these triangles can become very tiny and decrease thread group occupancy on the GPU, reducing performance"

I'm not experienced enough to say how true that is/how much of a difference it makes.

> If I understand correctly the second link is basically an extension of Loop-Blinns implicit curve approach with vector textures in order to find the winding counter for each fragment in one pass.

I've read the paper, but to be honest it's a bit over my head right now, but AFAIK MPVG is an extension to this [1], which looks like it's an extension to Loop-Blinn itself, so I think you're right.

[1] "Random-Access Rendering of General Vector Graphics" http://hhoppe.com/ravg.pdf

It's referenced in slug's algorithm description paper [1], the main disadvantage with Loop-Blinn is the triangulation step that is required, and at small text sizes you lose a bit of performance. Slug only needs to render a quad for each glyph. That is not to say that any one method is better than the other though! They both have advantages and disadvantages. I think the two most advanced techniques for rendering vector graphics on the GPU are "Massively Parallel Vector Graphics" [2] and "Efficient GPU Path Rendering Using Scanline Rasterization" [3]. Though I don't know of any well known usage of them. Maybe it's because it's very hard to implement them, the sources attached to them are not trivial to understand, even if you've read the papers. They also use OpenCL/Cuda if I remember correctly.

[1] "GPU-Centered Font Rendering Directly from Glyph Outlines" http://jcgt.org/published/0006/02/02/

[2] http://w3.impa.br/~diego/projects/GanEtAl14/

[3] http://kunzhou.net/zjugaps/pathrendering/

EDIT: I've only now seen that [2] and [3] are already mentioned in the article

EDIT2: To compensate for my ignorance, I will add that one of the authors of MPVG has a course on rendering vector graphics: http://w3.impa.br/~diego/teaching/vg/

I've once implemented the basic idea behind the algorithm used in slug(described in the paper [1], though without the 'band' optimization, I just wanted to see how it works), and I agree with you, the real innovation is in that quadratic root-finder. It can tell you whether you are inside or outside just by manipulating the three control points of a curve, it's very fast, what remains to be done is to use an acceleration data structure so that you don't have to check for every curve. That works very well for quadratic Bézier curves, in the paper it says that it can be easily extended to cubics, though no example is provided(and I doubt it's trivial). What I think would be hard with Slug's method is extending it to draw gradients, shadows, basically general vector graphics like you say. Eric Lengyel on his twitter showed a demo [2] using Slug to render general vector graphics, but I'm not sure of how many features it supports, but it definitely supports cubic Bézier curves. I'd also like to add that the algorithm didn't impress me with how the text looks at small sizes, which I think is very important in general, though maybe not so much for games(maybe I just didn't implement it correctly).

[1] "GPU-Centered Font Rendering Directly from Glyph Outlines" http://jcgt.org/published/0006/02/02/

[2] https://twitter.com/EricLengyel/status/1190045334791057408