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!
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.
> 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.
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.
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.