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!
> 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).
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.
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.
Yeah, they were in the editor and buggy as hell and you ran an increasing risk of crashing the tool the more of them you used. Also IIRC, they were indexed by letter of the alphabet and everything became impossible > 26.
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 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.
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.