SMIL export

[Emasoft]

I don't see "Export animations as SMIL SVG" on the roadmap. Please add it to your roadmap, it is very important. SMIL is the THE standard format for animations, used both for the Web as part of SVG:

http://www.w3.org/TR/SMIL/ http://codepen.io/search?q=smil&limit=all&depth=everything&show_forks=false

… and as the official OpenDocument format for animations and graphic effects:

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416228_253892949

Many professional animation packages can import, edit and save directly in SMIL. With SMIL support you can do in minutes things that would require days to do otherwise. It also provides an universal interchange format for animations. SMIL is the "lingua franca" of vector animation. Please support it.

[wraybowling]

Google is dropping SMIL support some time in the future. It is a rather nice animation spec that is still maintained by the W3C, but browser devs have had trouble with its performance and are favoring newer CSS and JS based animation APIs. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5o0yiO440LM

[Emasoft]

Google is NOT dropping SMIL support from Chrome, it is just replacing it with a polyfill based on the web animation standard. The web animation standard is NOT a declarative language for animations, you still need SMIL to describe animations in browsers. Eric Willigers from Google has created the official SMIL polyfill implemented entirely on the Web Animations API. You can find it here: https://github.com/ericwilligers/svg-animation This would allow the playback of SMIL animations EVERYWHERE, even in browsers that until now didn't supported SMIL (like old IE browsers). SMIL is the best declarative language for animations in the world, there is nothing like it. It's so powerful and still human readable. And offers advanced timing and perfect synchronization between animations and sound effects, something very rare even in closed and proprietary software animation formats.

[wraybowling]

Okay.. Be that as it may, the first step would have to be to even be able to export SVG, but SVG doesn't have a solution to the Steiner Tree Problem, which is why all this research has been done to create a new experimental vector format. So how would SMIL handle the kinds of animations VPaint produces?

[Emasoft]

You only need to render the resulting animation in SMIL. You don't need to preserve the steiner tree or anything else specific, no more than Photoshop needs to preserve layers when saving to PNG. You can still keep the internal VEC format, like Photoshop have its .PSD, but in the end all the internal structures should "flatten" in a sequence of basic tweening animations between the minimum number of keyframes you need to preserve the transformation, and the resulting product should be a SMIL SVG. If you save a VEC file today, I have NO WAY to use it or play it. No software opens it, no player plays it. I cannot give the VEC file to anyone. But if you can export in SMIL SVG, I can immediately use it everywhere, play it everywhere, share it with the world. I can import it in animation software, using it in video editing apps, publish it on the web or send it via email to anyone I want to check my work. People would then start using it, and SMIL SVG animations made in VPaint will start appearing everywhere. This is how you make a software like VPaint popular. This is why you need the option to export to SMIL SVG before anything else.

[wraybowling]

It makes a lot more sense to spend energy porting Vector Animation Complex to run on WebGL. It will take less time, will run identical drawing routines with similar performance, and WebGL is gaining popularity.

[Emasoft]

WebGL is a triangle-based rendering engine API. There is no way to tell WebGL to render a curve, you have to convert the curve in triangles and polygons meshes first. Also WebGL is a rendering engine, not a descriptive language for vector graphics images. You still need a language to describe the graphical elements and their animations. And the SMIL SVG language specification is the best standard available.

[dalboris]

Hi all, thanks for launching/animating this discussion :) I agree that "export animation for the web" is important. Somehow it got lost when I did the roadmap, but I will think about when it makes more sense to do it, and add it to the roadmap.

However, whether this "export animation for the web" is using SMIL, raw SVG, SVG + raw JS, SVG + JS library (jQuery/D3/snap.io/....), or WebGL is another question that I will not answer right now as I don't have enough knowledge about raw SVG animation capabilities, SMIL or snap.io yet, and how well this is supported or will be supported in the future (but I do have good knowledge of raw SVG without animation + animating SVG objects using raw JS, jQuery, or D3, and I do have reasonable knowledge of WebGL). The decision should take into account all your different arguments + other resources online.

In the long term, it would indeed be ideal to have web browsers supporting .vec directly, which is actually the -only- reason .vec is an XML format (in earler prototypes of VPaint, .vec was a YAML-like syntax, I changed to XML just in the hope that is improves compatibility with the web). I think it might happen if the core of VPaint is independent/flexible enough that web browsers can easily integrate it, both for parsing the .vec, and rendering it.

@Emasoft : A quick clarification concerning WebGL: yes, it is indeed triangle-based, but this is not an issue at all. In fact, quite the contrary, VPaint is already rendering using OpenGL, by triangulating the raw .vec representation (what you see on screen in VPaint is plenty of very small triangles). Exporting as a JS code using WebGL would be in fact what would create an animation guaranteed to be as close as what you see in VPaint, and would be probably the fastest to implement. That being said, I'm not saying that WebGL is the best option (having the SVG elements directly in the DOM is definitely very useful, and you can't have that with WebGL), but it's definitely an option to consider. Anyway, in the long term, it makes sense to have all this export options so users can choose what work best for them. The only question is to determine which one to prioritize first.

[Emasoft]

@dalboris As I said: WebGL is just a rendering engine API, not a descriptive language for vector graphics images. You still need a standard language like SMIL to describe the graphical elements and their animations.

[wraybowling]

@Emasoft No one is saying SMIL isn't important. From this point forward, the discussion can shift now to constructively proposing how exporting will work. If you think SMIL is an important technology, go research deeply how it works, read Boris' research, and see if you can come up with how VAC/VEC would translate over. That would actually help move progress.

@dalboris A rough sketch idea, based on what I know so far is that the half-edges would need to be converted to paths with a fill instead of using any stroked paths at all. Especially since VPaint introduced varied line thickness. So, then comes the terribly hard part: Using SMIL on path data needs to use the exact same number of control points in the same order. I don't know if VPaint does that already. From the looks of the 3D view... maybe? The best example you could possibly look at to explain this is Tavmjong Bah's post on morphing using the batman logo. http://tavmjong.free.fr/blog/?p=741

[Emasoft]

Translating the VEC format to SMIL is no different than rendering any animation to a sequence of SVG keyframes, and using SMIL "Animate". Here is an example SMIL animation of a running wolf: http://codepen.io/rafszul/pen/bNERPL And here you can found the documentation on the Animate SMIL instruction syntax used in the demo above: http://www.w3.org/TR/2001/REC-smil-animation-20010904/#AnimFuncValues The numbers in the field "Values" are the "Animation function values" that are going to be interpolated. Of course you can do something MORE complex, preserving as much as possible the original vector elements and animation paths. The good news is that you can do this in SMIL for pretty much everything but the VPaint special ability of merging multiple intermediate inbetween shapes in a single animation path preserving the topology informations. Maybe if you write down the specifications for adding to SMIL this awesome feature, you can submit it to the SVG Committee for the next SMIL v3.0 specifications approval. I know a guy, Tavmjong Bah, that sits in the SVG Working Group board, and I can ask him to submit your proposal. It would be awesome to have your technology in the next revision of SMIL.

[dalboris]

@Emasoft Unfortunately, things are not nearly as easy as you seem to think they are. I understand your wish to have a good SMIL export, believe me I do, and there is no need to convince me why that would be awesome (indeed, it would). Unfortunately, it is technically very hard to do (and I must insist on very), at least in order to have something actually useful.

More specifically, it is easy to do a crappy SMIL export (e.g., just bake every frame and forget all topological information, but it wouldn't be editable by hand anyway, so you'd rather do this as raw SVG or WebGL instead for maximum browser support), but very hard to have a good SMIL export. A good SMIL export, i.e. one that would provide benefits over raw SVG or WebGL, would take full advantage of the nice declarative language by exporting something concise and that can be intuitively edited by hand. This is what you want, right? Unfortunately, this is hard, because the ability to "intuitively edit by hand", as you can do in VPaint, heavily rely on the topological information stored by VPaint. Not only the ability to have shapes merging together as you mention, but even the ability to have three edges sharing a common vertex, or faces sharing common edges. Neither SVG, or SMIL, or actually any existing format that I know of, supports this. So during the conversion, you have no choice but to lose -some- of this topological information, and at the same time you lose the ability to edit it as intuitively as in VPaint. For the conversion to be any useful, it needs to be super smart about how to convert the full topological information (as stored in VPaint) into the subset of topological information supported by SVG/SMIL, i.e. it has to make a decision about what information to forget, and what information to keep, in a way that maximizes editability by hand. This is highly non-trivial.

Of course, if one day: 1) SVG was to support the per-frame topological features of VPaint (three edges sharing a common vertex, faces sharing common edges); and 2) SMIL was to support the animation topological features of VPaint (time-varying topology), then that would solve the issue. Unfortunately, after a lot of research, I am now 99% convinced of the following: it's not going to happen. Ever. Be as optimistic as you want, but I have been following all the activity of the SVG Working Group for more than 7 months now (I have subscribed to the SVG Working Group mailing list, and reads most emails and meeting reports), and even small changes are hard to get accepted since it raised so many compatibility issues not to break anything in any browser. And in our case, we're not talking about a small change. We are talking about completely revamping the data structure model. There might be something able to emulate "1)" in SVG in maybe 5 or 10 years, but concerning "2)", no way it's ever going to be part of SMIL. It is much more likely to get VEC directly supported by web browser, and this is where I think our long-term resources should go for a long-term "exporting to the web" feature. It gives us a unique opportunity to start from scratch designing a much better format, learning both from the strengths and mistakes of SVG without having to worry about backward compatibility. Now -this- would be a huge step forward for the world of web animation.

[Emasoft]

I understand. This is a very sad news. Are you absolutely sure there is no way to expand the SMIL language to include (natively, non emulating) 1 and 2? If that is the case then I agree that VEC should be much more than a VPaint custom format. You should aim to make it a true SMIL successor and a standard for vector animations. But then you need to incorporate in it all the advanced timeline, interactivity and audio/video realtime synchronization features that SMIL have. Currently SMIL is so powerful that you can create an entire animated interactive ebook for children with it, a complex videogame or an advanced multimedia textbook manual. This is because SMIL did what other vector languages didn't: it realized that graphic animations should already contain the means to synchronize and work with every multimedia element they are mixed with, otherwise graphicians are forced to convert or export it to other proprietary formats every time, loosing all interoperability and all the advanced features in the process. Please take your time to think deeply about the design of your new VEC language then, and try to build on the SMIL+SVG format, inheriting everything you can from it. Then maybe you'll have a true candidate for a SMIL successor. One suggestion: don't try to remake Inkscape in VPaint. It is a waste of time. Assume that people will draw the most important keyframes in Inkscape, Illustrator or Affinity Designer, because those three giants are what people studied on for years and take courses in academies. Those three are what real artists, those using Wacom Cintiq tablets, will ever use in the real world. Even japanese artists who use professional cel animation apps like Cacani have always one of those three giants installed in their workstation and use them for all the original vector drawings that do not originate from scans of hand made pencil drawings. Do not replicate what is already there. Focus on the animation work: keyframes interpolation, paths, walking cycles, layering, group motion/skeletal animations functionalities and onion skin to deform/draw the inbetweens from the already provided main keyframes. If you think to be able to make another Inkscape on top of creating the most advanced animation software and a SMIL successor candidate, you are just fooling yourself.

[dalboris]

Note that for now, I do not -intend- VEC to be intuitive to edit by hand anyway. I want this to be possible, but I don't want to encourage it by focusing on this. Complex animations are complex and cannot be edited by hand anyway, so I think it is better to have a well supported format with a range of apps to edit them intuitively. This means that I prefer to keep VEC as minimal as possible in terms of feature set to make it easier to support, rather than introducing too many high-level primitives, like SVG does. But yes, referencing to external media seems like something useful. For the time being, though, I prefer to keep core VEC non-interactive, but there could be an extension to add interactive features, say IVEC.

[wraybowling]

For what it's worth, I think it's better to think about The VEC format as an open-source successor to SWF the same way that PNG was a successor to JPG. None of those formats were really meant to be cracked open and edited by hand. It's totally okay if we leave that ability behind us.

[wraybowling]

I'll just leave this here: https://vimeo.com/71278954

[Emasoft]

I love that presentation by Bret Victor, and I understand that you want to experiment something new and not sticking with dogmas. But experimenting new ideas doesn't mean to forget what we learned. It means to use what we learned to build better systems.

So when you write: "I do not intend VEC to be intuitive to edit by hand anyway... Complex animations are complex and cannot be edited by hand..." you are just forgetting what we learned in the last 20 years of programming.

And what we learned is that both a scripting only language and a visual only language are wrong. The best result is a language that can be both edited visually without writing a single line of code, AND that produces a code that is still human readable and can be edited like an intuitive script language in any moment.

We learned that many times, in fact. It was a hegelian dialectical process of thesis vs antithesis that gave us such synthesis. For example the Microsoft way with Visual programming and Asp.net made programming as easy as drag and dropping components on a web page with the mouse. The IDE produced all the underlying code and it was very fun at the beginning. But ten years later programmers realized that that approach was a disaster. The underlying code was invisible to the user but it become progressively more bloated, more inefficient and too complex to be debugged. Change and evolution become impossible because changing anything would break all the previous underlying code, and nobody knew how to fix that anymore. Performances become worse at each release, and the drop in speed was starting to become exponential. Bugs and time wasted on debugging increased at the same rate. It became clear that such approach was a dead end. So people started rejecting all this and tried a complete opposite approach. They switched from visual development formats like Visual Studio and WebForms to an extremely lightweight and mostly command-line focused environment. Programming paradigms like Ruby on Rails, LAMP, MEAN, etc. become the new way of doing things. Even Microsoft in the end was forced to ditch Asp.Net, abandoning the bloated and unreadable web pages for the new lightweight Razor Syntax. At the beginning it was a breath of fresh air. Finally productivity and debugging were back. It was the antithesis of the previous paradigm. But after some years the script language approach started to show its limits too. The lack of structure made big projects hard to mantain. Lack of modularity produced with time more and more redundant spaghetti code, different parts and functionalities have hard time working together, and new features always broke backward compatibility. At that point it was clear that a new solution, a synthesis was needed. Frameworks started to appear that offers a new structured and modular approach. Facebook introduced React. Google introduced Angular. Then web components and Polymer finally appeared. And it was clear that that was the syntesis. With those you have visual components that you can just put together to build the web app, like in the visual original approach, but inside each component you have the code written in a very intuitive language, self contained and quick to write and debug by hand with any text editor. It was the best of both worlds: something so visual that can be used by someone with no programming experience at all, but at the same time a powerful system to create new components with just few lines of code, all without worrying about those modules working with each other thanks to the underlying frameworks architecture.

So, believe me when I say that to be successful, both on the web and on the desktop, your new VEC format must still use a description language intuitive and editable by hand like SMIL, while at the same time offering a visual tool capable of creating it without writing a single line of code. Please, I beg you: learn from the past if you want to innovate. Don't make the same mistakes people did again and again in the past. Make it even more advanced than SMIL or SVG, if you want, allowing people to create and define new graphic or animation primitives. That is something that will make such language easily to extend for any new graphic application, while still mantaining perfect compatibility. But do not create a non human editable VEC format: it will be a grave mistake and you will regret it.

[blurymind]

vec is more of a successor to fla files than it is to swf. Swf files are optimized for the web, where as fla files are more for editing. We dont yet have a standard successor to swf. Some people are suggesting SMIL to be the successor to swf

On Mon, Sep 14, 2015 at 11:03 AM, Emasoft notifications@github.com wrote:

I love that presentation by Bret Victor, and I understand that you want to experiment something new and not sticking with dogmas. But experimenting new ideas doesn't mean to forget what we learned. It means to use what we learned to build better systems.

So when you write: "I do not intend VEC to be intuitive to edit by hand anyway... Complex animations are complex and cannot be edited by hand..." you are just forgetting what we learned in the last 20 years of programming.

And what we learned is that both a scripting only language and a visual only language are wrong. The best result is a language that can be both edited visually without writing a single line of code, but that produces a code that is still human readable and then can be edited like a intuitive script language in any moment.

We learned that many times, in fact. It was a hegelian dialectical process of thesis vs antithesis that gave us such synthesis. For example the Microsoft way with Visual programming and Asp.net made programming as easy as drag and dropping components on a web page with the mouse. The IDE produced all the underlying code and it was very fun at the beginning. But ten years later programmers realized that that approach was a disaster. The underlying code was invisible to the user but it become progressively more bloated, more inefficient and too complex to be debugged. Change and evolution become impossible because changing anything would break all the previous underlying code, and nobody knew how to fix that anymore. Performances become worse at each release, and the drop in speed was starting to become exponential. Bugs and time wasted on debugging increased at the same rate. It became clear that such approach was a dead end. So people started rejecting all this and tried a complete opposite approach. They switched from visual development formats like Visual Studio and WebForms to an extremely lightweight and mostly command-line focused environment. Programming paradigms like Ruby on Rails, LAMP, MEAN, etc. become the new way of doing things. Even Microsoft in the end was forced to ditch Asp.Net, abandoning the bloated and unreadable web pages for the new lightweight Razor Syntax. At the beginning it was a breath of fresh air. Finally productivity and debugging were back. It was the antithesis of the previous paradigm. But after some years the script language approach started to show its limits too. The lack of structure made big projects hard to mantain. Lack of modularity produced with time more and more redundant spaghetti code, different parts and functionalities have hard time working together, and new features always broke backward compatibility. At that point it was clear that a new solution, a synthesis was needed. Frameworks started to appear that offers a new structured and modular approach. Facebook introduced React. Google introduced Angular. Then web components and Polymer finally appeared. And it was clear that that was the syntesis. With those you have visual components that you can just put together to build the web app, like in the visual original approach, but inside each component you have the code written in a very intuitive language, self contained and quick to write and debug by hand with any text editor. It was the best of both worlds: something so visual that can be used by someone with no programming experience at all, but at the same time a powerful system to create new components with just few lines of code, all without worrying about those modules working with each other thanks to the underlying frameworks architecture.

So, believe me when I say that to be successful, both on the web and on the desktop, your new VEC format must still use a description language intuitive and editable by hand like SMIL, while at the same time offering a visual tool capable of creating it without writing a single line of code. Please, I beg you: learn from the past if you want to innovate. Don't make the same mistakes people did again and again in the past. Make it even more advanced than SMIL or SVG, if you want, allowing people to create and define new graphic or animation primitives. That is something that will make such language easily to extend for any new graphic application, while still mantaining perfect compatibility. But do not create a non human editable VEC format: it will be a grave mistake and you will regret it.

— Reply to this email directly or view it on GitHub https://github.com/dalboris/vpaint/issues/35#issuecomment-139990426.

[dalboris]

@wraybowling Amazing talk, I love it :-)

@Emasoft « So, believe me when I say that to be successful, both on the web and on the desktop, your new VEC format must still use a description language intuitive and editable by hand like SMIL, while at the same time offering a visual tool capable of creating it without writing a single line of code. ».

Sorry, but for now, the focus of VPaint is non-interactive animation, and this doesn't need editability by hand. I mean, have you ever edited by hand a mpeg file? If you need interactivity, then you need scripting/programming, and only in this case it is useful to have access to the actual data representation. But even then, you don't -need- to, c.f. how Action Script is used within Macromedia/Adobe Flash: you edit it directly from the interface, you don't open the file directly. In other words, the "graphics" parts are only using the visual language (which makes sense), and the "programming part" do use both visual and text representation. That being said, I do want to make it as editable by hand as possible, as it is already the case. I just want to clarify that whenever there is a trade-off to do between "intuitive to edit by hand" and "functionality as a 2D animation package", I'd favour functionality. For many reasons, it's important that it is editable by hand (one is debugging), but it doesn't -have to- be intuitive. Only advanced users with programming knowledge should need to do this anyway.

[scribblemaniac]

I have been trying to limit my involvement in these exporting discussions as I am certainly not an expert in the various graphical technologies out there. I do feel however that I have to include my personal perspective on the matter, since I believe that it may bring some new insight and will hopefully bring some traction to a discussion that (as I see it) is currently spinning its wheels.

Exporting or importing from SMIL, SVG, Javascript, CSS, WebGL, some combination of formats, or even something completely different sounds great and I'd love to see some of these things become a reality, but it is something that we shouldn't even be worrying about right now. Our focus should be on creating a stable, fully-featured application to provide a foundation for things like this in the future. If the app can't even make what you want it to, then what does it matter if you could export it to Format X. Much more importantly, if we take the time to build quality import/export functionality then it will hold us back in the long run. This program is still beta, and it's entirely possible that new, cool, innovative features will be implemented (hint, hint :wink:). Depending on what changes are made, this could mean that lots of the work done for integrating another format could be broken or have to be refactored, added upon, modified, or even outright rewritten. This daunting task may deter developers from trying new things because then they will have to worry about maintaining these extraneous systems. All that time trying to keep the importer/exporter up to date could be spent doing better things. In summary, there are great ideas here for using other formats, but this is not the time to be worrying about them. This is a rapidly changing field and any arguments we make now are likely to be out of date by the time actually implementation comes.

Only advanced users with programming knowledge should need to do this anyway.

As an advanced user with programming knowledge, I think my stance on the matter of hand-editability has already been sufficiently covered.

I recognize that web integration is critical to many people who may be interested in using VPaint. Browser support for VEC files would of course be ideal, but that is probably not going to happen. What can happen however is the creation of a library that renders VEC files in a cross-browser manner. WebGL is probably the way to go for this. This won't be a trivial task, but I believe it is just as reasonable, if not more so, than having VPaint support something like SMIL. It could be argued that exporting to a preexisting format could make it easier to use other applications, but since almost nothing that I know of outside of web design uses/imports SMIL animations, this is a fairly irrelevant point. The current XML compatibility makes VEC formats fairly easy to read, and to prove my point here's a proof of concept I made in just a couple of hours of casual programming: https://jsfiddle.net/scribblemaniac/yhu9r5kx/ This only supports edge rendering, it doesn't do bounce playback, there are numerous bugs with animation, the code is messy, and overall it is just a terrible implementation but it serves to show that a cross-browser library isn't some fanciful dream, it's an attainable reality. In being separate from the main VPaint application, developers won't have to worry about breaking this because it won't affect the functionality of the main application, thus negating what I see as one of the primary issues with working with other formats.

While I am against implementing any kind of importer/exporter right now (beyond a single standard bitmap format like PNGs, and maybe SVG frames/multi-file sequences), I'm sure (@dalboris can correct me if I'm wrong) that if any of you are willing to implement and maintain such a feature, your contributions would be gladly welcomed.

[Emasoft]

I understand you guys, but you do not understand how the software ecosystem work. If VPaint will not produce a standard output like SMIL, an output that can be consumed by people, it is doomed to irrelevance. You cite SWF files as an example to follow. Really? The only reason SWF files where used for a while was because a plug-in was available for the browsers that can consume it. Now that mobile has sanctioned the end of plugins, and that such plugin is not in the browsers anymore, the SWF format is DEAD. Nobody uses it anymore. If you do not understand this, if you still want to ignore my advice, ok. But you are smart, and sooner or later you'll came to realize why I insisted so much. Good luck anyway.

[dalboris]

Oh, I just realize I still didn't answer that one! Thank you scribblemaniac for sharing your point of view and the awesome JSfiddle, it's great! I think you are spot on: now is too early to take decisions regarding support for existing file format, and that our time would be much better spent developing drawing/animation features. Only with a more complete set of features, and with the knowledge of how the file format ecosystem looks at that time, will be relevant to discuss it again. In the meantime, any "reasonable export", even if not perfect, is enough to get a little momentum without getting limited by feature sets of other format. I'll obviously accept any import/export contributed, since this doesn't clutter the interface at all and is obviously useful (even if not perfect).

@Emasoft "If VPaint will not produce a standard output like SMIL, an output that can be consumed by people, it is doomed to irrelevance.". I think you are overly pessimistic ;-) Yes, it obviously needs to produce some output otherwise it is useless, but it really doesn't have to be focused on SMIL to thrive. Two things: first, the primary focus of VPaint is animation for animated shorts and features films, not web animation. Even with just an MP4 export (possibly, per layer, channel, etc...), and the fact that it's open source (if studios have specific import/export needs, they can write it, most use internal proprietary formats anyway), then VPaint would still be relevant, and I do know very well what I'm talking about here. Second, even for the web, as long as there is some human-readable vector export suitable for scripting, then even if it's not perfect and is not SMIL, then VPaint is definitely not "doomed to irrelevance" for the web. It would still be very useful and used, and scribblemaniac just provided an amazing proof. It is totally doable to write a Javascript library that process the VEC format to render it (could be canvas, OpenGL, or direct SVG elements), and allow to add syncing with other media or user interactivity, in a declarative way similar to SMIL. Arguably, this is even much better than a native SMIL export, since Javascript is widely supported across browser and is definitely not going to be dropped in the foreseeable future, while the future of SMIL is much less clear.

In any case, I am glad that you started the discussion, it is an important one to have. I am definitely not ignoring your advice, it is very appreciated. Ignoring advises is plain stupid, it's not in my interest to do so. Be sure that I take your arguments very seriously, I'm using this input to take an informed decision, together with all other considerations which I am very knowledgeable of, such as technical limitations, and other use cases of VPaint. My conclusion so far is that SMIL support is a low-priority feature for now. It would definitely be nice to have, but I believe there are many other more important things to do first.

[blurymind]

If it's NOT going to be interactive, then a standard video file output in any resolution that is requested should be just fine. I agree with Boris that develoipment should focus on the actual animation tools rather than supporting more file outputs. at this moment vpaint is missing a lot of the fundamental features that make a professional animation application.

[Emasoft]

Here is an example of a cartoon animation file in SVG SMIL format. No javascript needed. Fully portable, standard, future-proof file format:

http://www.tbyrne.org/portfolio/smil/LoveDota.svg (warning: the embedded audio track makes the download sizing 1.4 megabyte)

This was created with the "Flash2Svg" plugin. It outputs an svg animation file using only the power of SMIL, no need for javascript:

https://github.com/TomByrne/Flash2Svg

[algorev]

I think there could be a much easier way to do this. Rethink about the WebGL proposition. If i'm not wrong, VPaint uses Qt and OpenGL, so i've got good news: there is a C/C++-to-javascript compiler named Emscripten that compiles C/C++ to javascript (indeed) AND it seems it can compile C/C++ code using Qt and/or OpenGL to Canvas/WebGL, and it produces very highly optimized code. This is the approach the Godot game engine chose for its HTML5 export option, and if it works in your case, there's no doubt you won't need that much fiddling with the format, as you could isolate some part of the editor whose role is to play the animation, modify it a little so it could be embed a .vec file, and ship with the distribution a javascript-compiled version of this .vec player, and all the program would have to do to export would be to save and embed the current .vec file in a copy of the player. The Emscripten website: http://kripken.github.io/emscripten-site/ Qt demos: http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos