I want to write an animated game which needs a lot of animations running all the time, something like rolling the cards/images in slot machine. I am wondering if I should mainly use just pure GWT/Javascript to run the animation, or use HTML5 Canvas or HTML5 animation to achieve this.
I know I might be able to make more fancy animated motion or graphics if I use HTML5 canvas, but I also cares about the performance more because there are several "animations" running in the same time just like rolling so many images in 5 columns slot machine. In this case, I think performance is most important.
I heard that drawing things in Canvas is really expensive. So I am not sure if I keep rolling images in Canvas is expensive as well.
What do you think which technique I should use to write a game like slot machine? HTML5-Canvas, pure JS/GWT-animation, or HTML5-animation?
I need to use some audio for the games, but I am pretty new to this, I do not know what libraries or technique I can use for audio. Please give me some advice.
Thanks.
if you have a lot of graphical animations, Canvas 2D will be a good choice. If you are dealing with vector shapes, simple animations SVG might be an option. I would not go for GWT as the abstraction layer of Java might hinder your ability to use full power of HTML/CSS/JS.
Ensure you use a basic game library if you choose plain JS and Canvas. I used jawsjs which is ok for simple games. See and observe the performance of below game which is based on Canvas 2D if you need a reference. Let me know if you need the code of it as a reference.
http://99challenge.com/_index.html
On audio, there are few challenges. Firefox behaves different to all other browsers, and has quite instable audio support. You might need to look for Flash support in getting audio to work properly on FF.
Related
What I'm looking is a flash alternative for mobile phones using html5.
I was looking into SVG and it seems the only way to get hardware acceleration is to use CSS transforms on it. But CSS transforms aren't enough, I want to animate the actual nodes that make up a vector (ie, points on a path) so I could get more sophisticated character animation. To do this I was looking at some gui based editors.
I checked what adobe has been up to and they seem to have killed Edge Animate and rebranded Flash as "Animate CC" for 2016.
http://blogs.adobe.com/creativecloud/update-about-edge-tools-and-services/
https://blogs.adobe.com/flashpro/welcome-adobe-animate-cc-a-new-era-for-flash-professional/
But reading up on "Animate CC" I see that it exports vector animations to either Canvas or WebGL. Which I think is due to them not getting hardware acceleration with native SVG via SMIL or using javascript.
https://css-tricks.com/guide-svg-animations-smil/
Another one is http://www.animatron.com which converts everything to canvas as well.
So my question is, in order to do keyframe animations on nodes within a vector path, a vector needs to be converted to either WebGL or Canvas for it to be hardware accelerated on mobile?
p.s I prefer using SVG as it's loaded in the DOM and I can manipulate things with jquery. This is for a mobile game that uses vectors (svg) as its base but I'd like to incorporate animations too - beyond the basic css transforms. I wish there was a way to have a .svg file that not only contains the vector information but also the animation info. so I could load this .svg file. and then in javascript go:
character1.play('animation1') or something. If SMIL worked fast I'm sure editors like adobe would make it as simple as that.
EDIT: I just read that Chrome 45 killed SMIL in favor of "web animations" and css.
https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animation_with_SMIL
And as Kaiido mentioned in the comments IE never supported smil so maybe that's why adobe never exported to it (?).
http://caniuse.com/#feat=svg-smil
also I never saw any examples online that show hardware accelerated path animation with smil, if any of you guys find a link pls let me know.
EDIT #2: I'm thinking of giving up my wishful thinking and instead looking at vector to canvas exporters like animatron.com. However, it doesn't seem like canvas is even hardware accelerated or fast like css3 transforms. I loaded some animations from animatron in my old iPhone 4s/iOS 8 and it's jittery and slow for example:
https://www.animatron.com/project/1953f3526e5b2ec4eef429c8
whereas css3 transform animations always run very smooth...
I still haven't tested vector to webgl.. but I think that's why adobe eventually chose to use it for their vector animations since canvas is slow and svg is limited.
EDIT #3: sure enough it seems like webgl is the way to go (unless someone finds a way to do this with native svg) http://www.yeahbutisitflash.com/?p=7231 .. this works fast in my iphone 4s/ios8.. I currently think this is the only way to do what I want: hardware accelerated vector based animation (however the graphics don't look as crisp as I'd want them.. webgl kinda messed with that I think).
but this is why I think Edge Animate got killed cause they were trying to create a tool that took advantage of css3 transforms, but ppl want to animate vector nodes so they went back to Flash and rebranded it. (another note: the above webgl anim doesn't work so well on my galaxy S4/kitkat android phone.. so this is mainly for newer devices/OSs)
EDIT #4: come to think of it. it'd be a pain to have multiple webgl contexts running in my program. so if I had 10 animated characters I'd have to have 10 webgl contexts which would be intense for a mobile device.. unless I chose to do the whole game in flash, and then I'd have one big webgl context after I export it. but I prefer to work in the dom. oh well css3 transforms for the meantime.. :/
EDIT #5 - Dec 2016: I'm now using svg/javascript with snap.svg. modern phones seem fast enough.
Other Useful Links I Found:
http://www.crmarsh.com/svg-performance/
Canvas is (as far as i know) software accelerated. So it's rendered by the processor (CPU). The processor (cause of them pixels) ain't that good at graphical stuff but for simple things it would be enough. And it runs everywhere, where there is a processor.
If you want to have better performance on hardware accelerated devices which most modern smartphones are, you need webgl. But you can export your stuff in webgl from adobe CC. Older smartphones are not very optimized on hardware acceleration so please check with your target group what devices they have and try to run your app on one of the slowest devices.
I would not use SVG. SVG is even worse than DOM. You can be faster manipulating HTML in javascript than SVG. I don't know why but it is damn slow. SVG is just an alternative if you want to have scalable graphics or charts and that's what it is made for. To animate in SVG is a pain. Don't do it. It is not optimized for animation.
CSS-Transform is a prototype-like and will not help you with keyframe animation. But it has potential to have an eye on it.
Does this help you?
This library/plugin might be exactly what you are looking for: Greensock SVG Morph Plugin. It seems to perform pretty well on mobile, not sure how well it performs on devices mentioned by you.
It's also not GPU accelerated but Greensock Animation Platform seems to perform extremely well even on mobile devices.
I think its a difficult question to answer as there's so many issues with different browsers. Some don't support SMIL transforms well (or being deprecated, but as mentioned there are fills for it), some don't support CSS3 transforms on SVG elements at all, so most of the 'solutions' out there, have some issue that may need to be compromised on. I think one browser doesn't support d attribute morph properly, but I can't recall which (so test this early on with required browsers if you do go down this route).
Canvas does typically seem to perform better on mobile for most animation I've seen or played with, certainly as the number of objects increases on page.
Other alternatives to webGL that was mentioned..
One option that kinda springs to mind is fabric.js, which is a canvas approach to SVG. It will take the same commands, elements as SVG, but display it on an HTML5 canvas. Turn off drag/freetransform within it (as I think its slowed down a bit with this if it needs extra checks), and I think it will be a bit faster, but its a while since I've played. This could be an interesting approach if you don't need specific DOM element access, but would be fine if you are ok with a similar object based setup.
If you insist on using SVG, then I would look at integrating it with another library (or even 2). Snap or SVG.js are both decent, but can be a bit slow. However, I would experiment with using Velocity.js or React.js with that svg library, as they have some methods that can squeeze out a bit more performance. Also GSAP may be worth a look.
There is no general answer to this, it depends on the browser implementation and your hardware, but ... for the long term solution I would bet on WebGL because it uses the GPU and will ultimately dominate.
WebGL is not well supported right now (2016), and it potentially comes with security issues.
Also see: https://css-tricks.com/rendering-svg-paths-in-webgl/
Canvas is better at working on raw 2d pixel buffers (+ alpha channel) and is slow for higher resolution+animation.
You could use some dual lib like Pixi though.
If you don't mind the k-weight increasing a bit and are comfortable using flash, the easiest and the fastest solution would be to use Animate CC (It's exactly Flash, without the symbol filters and gives canvas output instead of swf).
Long time Stack Overflow creeper. This community has come up with some incredibly elegant solutions to rather perplexing questions.
I'm more of a CSS3 or PHP kinda guy when it comes to handling dynamically displayed content. Ideally someone with a solid knowledge base of jQuery and/or Javascript would be able to answer this one best. Here is the idea, along with the thought process behind it:
Create a Full Screen (width:100%; height:auto; background:cover;) Video background. But instead of going about using HTML5's video tag, a flash fallback, iFrame, or even .GIF, create a series of images, much like the animation render output of say Cinema4D, that if put together in sequential order create a seamless pseudo-video experience.
In Before "THAT's JUST A .GIF, YOU'RE AN IDIOT" Guy.
I believe jQuery/Javascript could solve this. Would it or would it not be possible to write a script that essentially recognizes (or even adds) the div class of an image, then sets that image to display for say .0334ms (29.7 frame rate) then sets this image back in z space while at the same time firing in the next image within the sequential class order to display for another .0336ms; and so on and so forth until all of the images (or "frames") play out seamlessly fluid, so the user would assume he/she is actually seeing a video. Not a knowing it's actually a .GIF on steroids.
Here's a more verbose way of explaining the intended result:
You have a 1 second super awesome 1080p video clip (video format doesn't matter for helping to answer this question, just assume its lossless and really pretty k?). It's recorded at 29.97 frames per second. Break each frame into it's own massive image file, leaving you with essentially 30 images. 24 frames a second would mean you'd have 24 images, 60 frames per second would mean you'd have 60 images, etc., etc., excedera.
If you have ever used Cinema4D, the output I am looking to recreate is reflexive to that of an animation render, where you are left with a .TIFF per frame, placed side by side so that when uploaded into Photoshop or viewed in Quicktime you get a "slideshow" of images displaying so fast it look likes a video.
HTML would look something like this:
<div id="incredible-video">
<div class="image-1">
<img source=url('../movie/scene-one.tiff');/>
</div>
<div class="image-2">
<img source=url('../movie/scene-two.tiff');/>
</div>
<div class="image-3">
<img source=url('../movie/scene-three.tiff');/>
</div>
<div class="image-4">
<img source=url('../movie/scene-four.tiff');/>
</div>
<div class="image-5">
<img source=url('../movie/scene-five.tiff');/>
</div>
....etc.....
....etc.....
....etc.....
</div>
jQuery/Javascript could handle appending the sequential image classes instead of writting it all out by hand for each "frame".
CSS would look like:
#incredible-video img {
position:absolute;
width:100%;
height:auto;
background:cover;
}
But what would the jQuery/Javascript need to be to pull the off/can it be done? It would need to happen right after window load, and run on an infinite loop. Ofcourse audio is not happening in this example, but say we don't need it. Say we just want our End User to have a visually appealing page, with a minimal design implemented in the UI.
I love video animation, and really love sites built with Full Screen Backgrounds. But a site out with this visual setup and keeping it responsive is proving to strenuous a challenge. HTML5 will only get you so far, and makes mobile compatibility null and void (data usage protection). .GIF files are MASSIVE compared to calling in a .mp4, .Webm, or .OGG so that option is out.
I've actually recently played around with Adobe Edge Animate. Using the Edge Hero .js library I was able to reproduce a similar project to this: http://www.edgehero.com/tutorials/starwars-crawl-tutorial
I found it worked on ALL devices. Very cool. Made me think that maybe it's possibly to use this program or hit jQuery/Javascript directly to achieve the desired effect.
Thanks for taking a look at this one guys.
-Cheers,
Branden Dane
I found a viable solution to what I was looking to do. It's actually rather interesting. The answer it's introduces many interesting ideas on how we can display any kind of content dynamically on a site, in an app, or even a a full fledged software application.
The answer came about while diving hard into WebGl, canvas animation (both 2d and 3d), 2D video games techniques, and 3D video game techniques. Instead of looking for that "perfect" workflow, if you are someone interested in creating visually effective design and really seeing what the bleeding edge can do for your thoughts on development, skip the GUI's. Ignore the ads with software promising to make things doable in 5 min. It's not. However we are getting there. 3 major events we have to look forward too in just a few months are
1.) the universal agreement to implment WebGL natively in Opera, Chrome and Firefox (ofcourse), Safari will move to ship with webGL enabled, compered to the user having to enable it manually, and even IE is going to try and give her a go (in IE 12).
2.) Unity 3D, an industry standard in game development, has announced that next month it will release version 5, and with it a complete, intuitive workflow from start to exporting in Javascript (not JSON actual JavaScript). The Three.JS library more specifically as it is one of the most popular of the seemingly endless games engines out today.
How does this answer my initial question?:
Though WebGL has been around for about 3 years now, we are only now starting to see it shine. It's far more than a simple video game engine. With ThreeJS We have a full working JavaScript library, capable of rendering in WebGL, to the Canvas, or EVEN with a few CSS3 magic. Can't use your great movie as a mobile background? It ruining the overall UI? Cheer up. ThreeJS can working with both 2D and 3D javascript draw function, though not at the same time. Hover other libraries exist that allow you to bypass this rule.
AND DRUM ROLL. It is, or can be very easily made in a responsive or adaptive way.
The answer to my question came from looking at custom preloaders. Realizing I can create incredible looping animations in AE, and export them as GIFs offered the quality I wanted, but not control, no optimization, now sound. However, PNG Sequences CAN be exported. Then the epiphany hit. Before I just say what I am using to solve my problem, I'd like to leave a list of material anyone looking to move beyond easy development and challenge limits can use as a reference guide. This will be in order with what I began to where I am now. I hope it helps someone. The time to find it all out would be very much worth it.
1.) WebGL-Three.JS
WebGL opened my eyes to a new world. It's a technology quickly evolving and is here to stay. In a nutshell, all live applications you create now have access to more than just a CPU, but also the Graphics card as well. With GPU's getting more and more powerful, and not so unreasonably priced, the possibilities are endless. The idea we could be playing Crysis 3 "in-browser" without the need of a 3rd party client is no fiction. It's the future. Apply that to websites. Mind blown.
2.) First Cinema4D, then start working around with Verold.com & PlayCanvas.com
C4D is just my personal favorite because if it's easy integration with AE. You will find that with exporting your 3D models, Textures, Mesh's, anything to Three.JS (or any game engine period) that it is Blender that is the most widely supported. As of writing this, their are 2 separate C4D workflows to ThreeJS. Both are tedious, not always going to work, and actually just unnecessary. PlayCanvas was also a bit of a let down. Verold, however is an EXCELLENT browser based 3D editor in which you can import a variety of files (even FBX with Baked animations!) and when you are satisfied you can export into a standalone client or an iframe. The standalone client is superb. It is a bit glitchy, so have patience. You shouldn't get comfortable with it any way. Go back to your roots.
3.) iPhone app development, Android app dev (to an impressive extent), Web Sites, Web Apps, and more all function in a way that an application need only be made using JavaScript, HTML/5 and CSS/3. Once this is understood, and the truth hits you as to how much control you may not have known you had, then the day becomes good indeed. Learn the code. With a million untested and horrible "GUI's" out there that claim to do what you want, avoid the useless search. Learn the code. You can never go wrong at that point.
4.)What code do I need to learn?
JavaScript is the most essential. More on that in a moment. Seriously dive into creating apps of any kind with ThreeJS. Mr. Doob (co-creator of the library) has an EXCELLENT, well-documented website with tons of examples, tuts, and source code for you to dive into. Chrome Experiments is your next awesome option to see how people are really taking this kind of development to a new level. In the process of learning ThreeJS, you'll become more proficient with JavaScript. You will also start to play with things you maybe never had to, like JSON, or XML files for packaging data. You'll also learn how simple it is to implement Three.JS as a WebGL render, or even fallbacks to Canvas and even CSS3D if and when possible.
Before going on, I will make a caveat. I believe that once Unity 3D drops ThreeJS fro pro and free users, we will see much much more 3D in the web. In that case, it can't hurt to Download the software and play around a bit. It also serves an an excellent visual editor. There are exporters from Unity 3D to ThreeJS, but again they are still pre alpha stage.
2D or not 2D. that is the question
After getting a little dirty with 3D I moved into drawing in the 2D realm using the canvas. Flash still seems like a viable tool, but again, it's all about the code. Learn how to do it and you may find Flash is actually costing you time. I found 2D more difficult than 3D because the nature of 2D has yet to radically change, at least in my lifetime. You'll need to start learning Spritesheet creation tutorials. Nothing incredible hard if you know where to look. Use A photoshop, or an equivalent application. Create as many "movement" frames that if were put together in a GIF would be enough to seamlessly loop the sprite. OR render a master image out and cut around the elements naturally distinct pats. Ex: You want to make the guy you have standing on a street corner you created, stays. Cut that character up in as many separate PNG files as you believe you need. The second method is all about using the same sprite sheet we brought in the first try. The first scenario meant writing CSS selector and have javascript written for the regular user would become increasingly difficult.
First solution: Using CSS and Javascript to plot "frames" meticulously put together in the sprite sheet. This really can become a pain if not done correctly all the way through.
Second solution: We lose the frame by frame effect if we need it, but our overall 2D animations will look incredible. Also, building in this way creates more efficient games when implementing physics engines and setting up collision detectors. We will still use the same sprite sheet, however we only need to choose the frames we really actually need. The idea is to use dynamic tweening between frames that are called together via Javascript. In the end you have a fully animated Sprite, but could have done so with just one frame. Ex: You have a Stickman you want to show walking in a straight line. Solution one would jump frame by frame, creating a mild chop, to illustrate an animated walk. In solution 2, we take the Stick man and chop his dynamic bits apart so we can call them through JavaScript, then build our sprite from JavaScript directly. To create the walking effect, we cut apart stickmans legs and have those separate in the sprite sheet from the rest of his body (unless you need to animate another body part as well). We map out where the coordinates are for each piece of stickman. Free software like DarkFunctionEditor is one of many programs that will instantly take care of generating for you a reliable sprite sheet, printing out the coordinates of your sprite sheet after you bake it. With this knowledge, head into JavaScript and call in your variables that you wish to associate to the pieces of Stick Man and their corresponding coordinates. Then use Javascript to "build" all the pieces together. The walking animation is accomplished by the Tween we talked about earlier. Each leg essentially runs on a beautifully fluid path you set in JavaScript. No chop. Very easy to customize and control. If you want to make it even easier for yourself, try using one of the many libraries for Sprite animation. My favorite at the moment being CreateJS.
If you are looking to include collision detection or create particle systems then you will need a physics engine. For 2D I am torn between 2 at the moment. Right now I would put PhysicsJS over KineticJS. Both are fantastic. I believe PhysicsJS integrates with CaccoonJS and other mobile scripts easier.
My last words of advice are=, after reading this, understand you will be working will JavaScript. You will have a bit of jQuery to make it easy, but you will encounter things that are difficult on the way. My HUGE recommendation is to move into learning how to build using NodeJS. It's an Asynchronous Javascript Server-side and client-side development space. The documentation is wonderful. Your first stop should be learing about npm, and bower. Then understand how to effectively implement Grunt into the workflow. Try out NodeJS assets like Yeoman to give you "boilerplate" Node setups from which to start with. After you start understanding NodeJS mechanics and feel comfortable with setting up your initial package.json, you'll find that all this JavaScript will almost feel like it's writing itself after a certain point.
And that's all you need to know to get into 2D and 3D design and development. My initial question could have been answered using say a 3D rendered fullscreen. However my final conclusion came in a different method entirely.
After learning about 2D sprites and framing, then noticing the encoding process of gifs. I had the idea to try and create PNG Sprite Animations. Not PNG Gifs, per say. But rather creating a 2D scene and using a PNG sequence that I would then animate via JavaScript. I found a few great libraries on Github, both for my idea and cool ideas for GIF manipulation.
My final choices was with the Github Repo "jquery.animateSprite" Instead of mulling through sprite sheets, you take your individual PNG's and this library gives you an incredible amount of control in how you can store variables for later use, but also the animations you can pull off in general. For a full screen, responsive background that works on any device (and can even be animated to sound....) I'd recommend this technique. It works much like a flip book animation works, except much much more effectively.
I hope this helps someone along the way. If you have a question on anything I have mentioned here, or know of an area that needs further detail, then by all means please let me know.
-Cheers
I have been recently into developing more with html5 canvas & as I see, it is more of JavaScript. So when should it be preferred over plain html? All I want to know is that given that I have to develop a game say like pacman, which one should be better to use? (May be for drawing applications canvas is a lot more helpful than using divs)
For example here are two implementations of pacman
Using divs' and javascript
Using html5 canvas
I would like to know the pros and cons of developing a browser game with canvas & with html div's and js. Also I want to know when is it better to use canvas & when is it better to use plain html & js.
if backwards compatibility isn't a concern, use a <canvas>, this is exactly what they were designed for.
An array of pixels is far more efficient than creating a DOM element for every single dot on the page.
I believe one of the major distinctions between the use of canvas or html (dom) for something like a game is the trade-off between the dom helping you to mangage your objects by providing the mouse events to hook, or you managing them in JavaScript yourself.
You need to handle all the mouse events yourself if you use canvas for a game, there are libraries to help you do this, one such library is EaselJS. This library will help you to easily add listeners to your objects in canvas.
Obviously not needing to have all your objects in the dom, you get a massive performance benefit if you require any scrolling etc. Take the Google Maps fusion tables layers as an example, they can render 1000s of markers on the map using canvas and maintain a great user experience, this was something that just wasn't possible when using the dom.
So its all about the trade-off, libraries and more code to manage your objects in canvas - but reap performance rewards, or ease of development in html (dom), but possible performance hits for many objects.
For a simple 2D game I would go the canvas way.
For 3D games you will have to take a look at WebGL ( which is a native browser implementation of opengl ) and probably a webgl engine like copperlicht which will wrap the webgl api for you. You can also do 2D games with WebGL, and if your 2D game is graphics heavy, webgl would be faster than canvases.
Of course there is also the Flash solution, but I would not go that way.
edit: theoretically you can also make 3D games with just canvases but that would mean reinventing the wheel ( transformations etc. )
HTML and DOM for graphics are slow, but they will work in older browsers.
Canvas is very fast, but does only work in modern browsers.
So, if your target group is modern smartphones or modern browsers, then definitely go for canvas! Moreover, if you need certain special effects or particles, then there will be no other way than to use Canvas, since this cannot really be done with the DOM.
Perhaps SVG might be an option for you? It is not as messy as pure html, which is not suited for games, but provides better browser-support. There is also a good framework for SVG: Raphael. I myself used SVG for some game-implementations. (risk, tetris...)
I think there are two diffrent solutions for the problem:
1) First the solution shown by aves Engine, which renders the whole game with html elements and external stylesheets e.g. CSS3 transfomations. Pro's are that the event-handling is much easier when working with div's than by rendering on canvas.
2) Like isogenicengine.com shows you could render the game on html5 canvas element. Mabye that's the better solution, because rendering on canvas is the way that millions of 2D-games were written before and in future the industry will optimize the drawing methods e.g. with hardware acceleration. At the moment the contra is that rendering on canvas is slow if you would like to render in fullscreen. If you would like to render only in a specific area of 200x200px that's okay, but in fullscreen you get stuck with a framerate of 10fps.
What do you think is the better way to create a game for the web?
Thanks for your opinion!
PS: If you have some articles about the topic please paste some links
I don't think it's a clear one size fits all kind of thing. I really think it depends on what you want to do with your game.
If you are doing a lot of vector graphic manipulation, perhaps canvas is a better choice vs engine like aves. For tiled based, maybe aves will work better.
You can render fast on fullscreen canvas if you're clever about only re-rendering dirty regions. But if your whole canvas needs to change every frame this obviously isn't going to help much.
I've spent alot of time recently looking into this issue and my conclusion is pretty simple.
Use HTML Elements, lets say that HTML5 actually makes progress and in one year the major browser support it. How long does it then take to get the general user base of the web on the latest browser (IE6 still has a choke hold in some sectors). So making the game available to as many people as possible is key! (In my mind anyways)
If however, your looking to learn and develop, go with canvas.
I have an idea for a website which involves a canvas area which has no limit to its size. Basically you would be able to add items to the canvas (notes, photos whatever really). You would then be able to drag the canvas which would move those items along with the canvas until they disappear of screen. If you dragged the canvas back the other way they would appear again.
Question:
Which would be the best suited to this type of thing, Flash or Javacsript?
My main worries are the speed at which javascript/ flash could handle moving multiple items around on screen in the way discribed. Which language would handle better for a user on a slow machine.
UPDATE:
Thanks for your opnions guys, but to clarify what are the benefits of canvas over straight jQuery DOM manipulation? or visa versa. I've never used canvas before.
I don't think this is a question that will get you an objective answer - Flash developers will tell you Flash is better, web developers will say JavaScript. Trying to remain objective, I'd say that both technologies are suitable for what you describe, but have different advantages.
Flash will definitely render faster, even on slow machines, and is much richer graphically.
JavaScript is more accessible and works on a greater number of devices. Use a good JS framework though.
My initial thought would be to go with Javascript - if it's good enough for Google Maps, it's probably good enough for your app too.
Do you need to use canvas, what you're describing could be done with just javascript and the DOM. It would perform perfectly well unless there are a huge number of elements and it would be cross-browser compatible. For canvas you would require exCanvas to support IE which can sometimes slow things down.
The best way would surely be Javascript. And I would even say that you should reconsider the use of canvas. It sounds like it could be done in pure DHTML. In that way you wouldn't lose support for IE.
Consider using one of the javascript frameworks; Prototype or jQuery come to mind. It will ease your coding immensely. Given the development in javascript-engine performance (next versions of Webkit (Squirrelfish Extreme) and Mozilla (TraceMonkey) will be lightning fast) the worries about performance may be moot.
Also if you decide that you can't do it without canvas consider using John Resig's processing.js.
I'd say go with flash (or DOM if you don't need the extra punch). Here's my reasoning:
You can do cool transformations with canvas (skewing, rotations, gradient fade-ins in images, reflection effects, etc) that you can't with DOM. The downside is that doing these cool things is math heavy.
Canvas doesn't work in IE. IE's equivalent (VML) apparently has a root-access security hole.
The DOM has been around for longer than canvas and since it's more widely used (and depended upon), it's more optimized and polished than canvas.
The Flash community has a lot of good free components available that may already do what exactly you want.
Flash and DOM have a lot of good documentation and tutorials, canvas not so much.
Flash can do pretty much everything that the DOM and canvas can, plus audio, video and grabbing input from your web cam.