I won't lie, I'm having a hard time using this app. I spent awhile looking for a create keyframe buton and almost gave up before realizing how to do animations. I still don't know how to build custom shapes with curves or how to draw shapes that exist for a short duration. When I published the canvas element it didn't animate in the browser.

Clearly you've solved a lot of interesting technical problems, but I feel kinda clueless while using it. As far as I know the only people who use the flash authoring environment these days are advertisers and animators (or designers building content for flex apps). So if you want to focus this, I'd say go after those people. When people do make flash sites in the authoring environment they usually rely heavily on simple onclick and gotoandplay statements.

I'm impressed with what I see, but I don't know what problem has been solved.

Yeah, I completely see what you mean. That's pretty much what I meant by "abstract ambition" in my original post. I feel like I've spent a fair bit of time building modules that are generic enough to be the basis for a few different apps, but the whole doesn't yet do anything specific well enough.

That's why I felt like I need to release this sooner rather than later. It would be appealing to go on polishing the app for an imaginary customer who happens to be just like me (my other application, Conduit Live, went down that drain)... But it's healthier to face criticism and try to figure out if there's some potential customer group(s) out there that I didn't anticipate.

FWIW, I feel like there might be something interesting to be done in the intersection between realtime graphics and video on the web. Flash has a lot of cool technology, but nowadays you need to be a coder to take advantage of the new stuff like Pixel Bender shaders or the Alchemy compiler -- Adobe seems to have "outgrown" the designer audience who originally made Flash a success, and I think that's a mistake.

Re: your points about Radi -- there's a big hole in the <canvas> publishing functionality currently, it doesn't export all keyframes. Sorry about that, I'm hoping to fix that ASAP. The keyframing UI is not very well thought out, and needs a lot more work. To make polygon shapes, choose "Draw Shape" from the toolbar and click away in the viewer. There's no exposed way to limit the shapes' visibility in the timeline either (internally there's a concept of empty keyframes same as in Flash, but it's not in the UI).

I don't think it can be stressed enough how important it is to prevent feature creep while you still have the chance.

I can't imagine the repercussions of cutting down the program down the line after people have acquainted themselves with it - to the point of feeling completely entitled.

Aren't the side projects the real projects in the end? :)

I remember when we had to design a service and an interface for it in Flash in college. The university did not provide an Adobe license, so the license would run out right around the examinations, assuming you hadn't installed it earlier to play around with. They basically wink-wink-nudge-nudged people into pirating the whole thing.

Had we had something like this, things would have been so much easier in every conceivable way. Working with Adobe Flash was perhaps the worst experience of my time in college.

It's funny to think about sites like newgrounds.com and kongregate.com and how HTML5 might challenge the domination of Flash.

A truly incredible piece of software pavlov. Well done!

What does that phrase mean, "software pavlov"?

The OP's name is 'pavlov', and your parent should have included a comma.

Couldn't this be used as a replacement for Flash? I know one of your selling points is that you can do some rather amazing visual imagery without needing any programming skills; but what if you coupled a basic image/video/animation editor with scripting abilities (javascript)? You would have a nice alternative for tired-of-flash developers who create sites like the Droid product page, pretty much every movie landing page, and every video game product page. You know Adobe is already working on it, and Dreamweaver is already integrating HTML5. But build something on open standards, not tightly integrated to any one image/vector editing software, and you would have a strong market.

Why is there no browser engine? It would seem like your method of "writing my own of everything I need" doesn't really scale well to something like the entire browser stack. And it appears that WebKit should not be that hard to integrate (in the general case, not sure about this kind of authoring app).

You may have a good reason, I just can't think of it off the top of my head.

Well, of course the real reason is simply that I wanted to make use of the stuff that I already had written, which consisted primarily of a fast compositing engine with JavaScript hooks. (I'm not one of those people who want to start from scratch for each project.)

But I do think there is a solid case for this approach. Consider something like image filters and applying them to video. If the authoring UI were implemented in WebKit, I don't know how I could get realtime responsiveness for video manipulation. Now it's no problem in Radi because the rendering bottleneck to produce actual browser-playable <video> content only happens upon publishing.

Being on the native side gives me a theoretical edge when it comes to new browser features -- I'm thinking of something like visual effects which may be supported only by Mozilla but not WebKit, or vice versa. Not being married with a specific engine could be an advantage.

It's worth mentioning that Radi does actually use WebKit to render the content in HTML layers. So you can place custom HTML within a document, and it's rendered with browser-style text antialiasing within the app. (It's not dynamic, though -- just a snapshot of the HTML rendering.)

Looks awesome. Whats your email?

Ah, didn't see that. Thanks

There's a contact form at http://www.radiapp.com/radiapp/feedback/.

>Although the app targets HTML publishing, the compositing core doesn't actually use any kind of browser engine like WebKit. Instead, it's a node-based GPU-accelerated compositing system of my own devising. Layers and effects are rendered using OpenGL. ...private implementation of the [DOM javascript API] etc.

http://i.imgur.com/6BC1o.png Recoil/long-neck guy, a meme. Pardon the banality, but it's what I actually did when I was reading this.

You are one ridiculously industrious individual. Congrats, I can't wait to find an excuse to tinker with Radi. :)