Hacker News new | ask | show | jobs
by gb 5945 days ago
Actually a lot of Flash apps are mainly code + assets now, that's certainly the way we make things.

I've tried using canvas to replicate some things that we've made in Flash, and quickly ran into some problems:

1) There is no way of interacting with elements drawn to canvas, as it's just a flat image (as someone else mentioned in the comments here, canvas is just a way of drawing bitmaps). You could obviously write your code to deal with mouse and keyboard interaction, but it's even more overhead on something that is already quite slow, and even if you could interact with individual elements it brings me to the other thing...

2) Flash has everything in layers that can be updated independently, when it comes to canvas if you want to change something you have to redraw that section of the image entirely, something that isn't always practical which means you end up redrawing the whole canvas. Essentially Flash does the same thing, but as the compositing is handled by the plugin it is far faster than anything you can do in Javascript at the moment.

Also related to the above, the drawImage method that draws bitmap data to the canvas is painfully slow at the moment, so compositing using that is out of the question. If that can be optimised significantly it will certainly help.

Basically canvas is too low level to duplicate the kind of functionality Flash offers at the moment. Until manipulating the canvas and Javascript is optimised further it's not possible to layer in the interaction or flexibility of rendering that Flash has. I'm sure a framework offering this will happen one day, but it won't be any time soon.

2 comments

1) I'll seriously disagree with you on this. Flash is likely much easier, because it's designed around doing this, but it's easily possible in Canvas too. Just maybe not currently. An OpenGL-like pipeline to help figure out what you clicked on, combined with JavaScript objects that can draw themselves, allows identical behavior. I don't know about interaction speed, can't comment on that. And I'm only using OpenGL as an example because I have some idea of how it works, there are other ways to detect what was clicked.

Heck, if you wanted, you could literally duplicate OpenGL in its entirety in JS for Canvas. There's nothing preventing this, except lack of threading / parallel processing, though I admit it'd be ungodly slow.

2) Also primarily a problem currently, and likely due mostly to the lack of mature libraries to do just this. With compositing rules (source-over, source-atop, etc) and masks for objects, you can re-render only the displayed portion of any object on a Canvas as well.

Low level: well yeah, it's a thin layer over a bitmap surface. Libraries are needed to abstract away from that. It's kind of like saying that OpenGL isn't fast because it's core is low-level. That low-level feature-set Canvas has will be wrapped in libraries to make specific uses simpler, I guarantee it. Speed will come, especially as Canvas gains focus. It's still very new. Was Flash this fast/capable in pre-1.0 days? I have no idea if it'll catch up / surpass Flash, but it's far from its optimum right now.

I'm not calling for the death of Flash, and I seriously doubt it'll ever supersede Flash on everything, so Flash has it's uses and will continue to do so. Just pointing out that they're not on equal playing grounds in terms of development.

Actually I think you just agreed with everything I was saying!

My point was canvas isn't quite there yet, not that it never will be, and also that I think the Flash-has-an-editor argument isn't the reason why canvas isn't ready yet.

As a side note, I'm already one of the people writing a library/framework to overcome the things I mentioned, the problem is I don't think it's going to be fast enough to do much with for a while.

Aaah, ok. I was keying in on the "There is no way of..." and "have to..." to mean you thought it was impossible, not that it just wasn't easy currently.
I briefly considered writing some kind of framework for Canvas that would emulate the Flex DisplayObject and related container classes together with some useful behaviors.

I gave up when I realized how big a task this would be and that the result would probably be slow and almost surely superseded in some future release of Canvas.

It depends what side of it you're trying to do, just getting a tree structure of Sprite-like things working is actually quite easy - canvas' drawing transform stack is ideal for resolving the nested transforms for each shape. The trickier part is re-rendering the smallest region of canvas possible when you do change part of the display list.

Maybe I should post a link to my stuff when I get around to working on it some more!

It was the event handling side of things that I realized were going to be a fair bit of effort - all standard graphics stuff, but not things that I was particularly interested in writing at this moment in time.

Having said that, if you do have something along these lines I would love to hear about it.