I'm new to html5 and have been playing around with the canvas. I'm wondering when the canvas would really be necessary/useful? i.e. when is it meant to be used?
If i need to do simple animation, like move tags around, do i really need a canvas or is it better/easier to just use jquery/js?
With help of canvas you can create 2D graphic applications, animations, simple transformation of images (like rotating them), GUI etc. Some examples:
Asteroids game
jigsaw puzzle
About GUI, unfortunately I can't load a site, no idea why... it was called iWidgets.com, the only thing I've found is a screenshot. You can see blue pipeline there, they bound elements. It was done with help of canvas; while moving elements, pipelines also were redrawing; when you change active element all its connections changes color to yellow (so you see dependencies). Nice project, I hope it is not accessible just for a while...
Good article about how to use it is here
From "An insight into the HTML5 Canvas Element":
The canvas element is interesting and
worthy of focus because it enables,
for the first time, direct drawing of
graphics within a browser without the
use for an external plugin like Flash
or Java. The beauty of canvas is that
it’s controlled entirely via simple
JavaScript code, meaning it builds on
the powerful functionality JavaScript
already provides and doesn’t require a
crazy learning curve to use.
Choosing to experiment with canvas
over other new elements was simply
down to it’s functionality as a
graphics platform, which inherently
makes it a potentially interesting and
rich platform to play with. It was
decided that pushing the flexible
canvas element would produce the most
interesting results that we can use in
the application.
Another deciding factor for choosing
canvas was to test the animation
capabilities and the possibility of it
being a potential Flash replacement.
Now Flash obviously has features that
canvas could never emulate, however
it’s an exciting concept nonetheless
to see exactly what could be achieved
with canvas that would normally be
done by reaching for Flash.
read that article to get more useful information
PS. If your animation is about tags moving (like parts of your page), then canvas does not fit. Canvas is for graphic rendering. So in that case you will use jquery or other JS libraries.
Here's the best practices for deciding when to use CSS3 Transitions / Animations or Canvas. Keep in mind that if you're using jQuery, under the covers they will be using CSS3 transitions or animations when possible.
CSS3 Translations / Animations - use these if you're animating DOM element styles, such as position and size
Canvas animations - use canvas animations if you're animating something more complex, like if you're creating an online game or building a physics simulator. If you're animating 3-d models, you'll definitely want to use canvas so that you can leverage WebGL
Canvas gives you access to the pixel level of the graphics. If you wanted to do a checkerboard transition you could do that with a script in canvas but not in jquery.
For a few examples of what is possible (already been done) see http://www.netzgesta.de/transm/
Related
I'm implementing a HTML5 game using canvas. Now I'm thinking about making all text overlays like tooltips, speechbubbles, infowindows and so on using HTML elements with position absolute over the canvas. So I can use many effects and transitions CSS3 offers.
But I'm not sure about performance. These overlays have to be added and removed frecuently (is something MMORPG like, so there will be a lot of speechbubbles and so on).
There are probably 2 questions regarding performance:
DOM traversal to add/remove. Maybe a cache can help?
HTML and CSS3 itself.
The other option is to manage these elements in the canvas itself, drawing them each frame. But maybe I have then again a performance penalty, because of the extra code, timeouts and stuff I would have to add, to achieve similar effects like in CSS3. And traversal of some data structure would be needed anyways.
Any advices, opinions, experiences?
Thanks in advance.
Consider using only one of the mentioned two technology. May be you can release that application in mobile or tablet. I think on these devices would be issues with handling both the same time. And another thing: if you stay in canvas there would be no worries about compatibility. Its not a techy but a thought-provoking answer.
The single best reason for using the DOM for UI elements in HTML5 games is event handling.
If you draw everything on canvas you will need to write your own logic to handle clicks and decide what has been clicked on, which can soon become very complex, expecialy if you have multiple layers of interface.
With DOM elements (especially when using a library like jQuery) this is trivial, and you can create a rich and interactive UI with minimal effort.
The only downside I can think of is that you may encounter browser inconsistencies, especially if using CSS3, but again jQuery will help with this.
I suppose another downside is that once you go down the DOM route, your game is always going to be a browser game, whereas if it was 100% canvas, there would always be the possibility of porting the code to another language and making it native, but I guess that would only be a downside for some people.
One way to approach this is to use a "dynamic" image map behind your canvas object. Then you can use the dom as required. Note you will need to pass the clicks on the canvas through to the image map.
We are in the research phase of a new project which will be used in the advertising arena. Users create a bunch of items that will play in different regions on the screen and can then swap out animations (images/texts etc).
We are pushing for an HTML5 solution which will be responsible for the rendering but a new proposal is to just use SVG (and SMIL).
I know you can embed SVG content in HTML5 pages and there are numerous links comparing the canvas and SVG.
What I need to know is what are the pros and cons of going for a solution which is based on HTML5 compared with a solution that is based solely on SVG? Also for the long term plans of the project, I can see HTML5 as allowing so much more.
Also I am not sure what tooling support is available for users using SVG. Most of items must be templatable (changing text/images), is this at all possible?
TIA
JD
I've recently had an opportunity to try Raphaël, an SVG-based solution, and Flot, an canvas-based solution. Both provide emulation on browsers that don't support the primary format: Raphaël uses VML on IE, and Flot uses excanvas.
Both SVG and canvas have advantages and disadvantages. Both can draw shapes, paths, and embed images, but canvas can do pixel-level manipulation and can draw a lot more sprites quickly, which is why it's becoming popular for HTML5 games. SVG has more powerful paths, although you'll have to learn the syntax.
SVG has another really interesting advantage: elements on a chart are DOM nodes, so it can use browser mouse and click events as well as add, remove, or change an individual node without redrawing the whole chart. Doing the same thing on a canvas involves manually keeping track of the locations of every visual element and redrawing the whole canvas when stuff moves. (Canvas does let you do double buffering and caching stuff sop it is possible to redraw it quickly, but the logic of keeping track of where everything is is still on you.)
For that reason, I think SVG is a better choice for interactive graphs and charts, while canvas is more appropriate for advanced graphics. In either case, cross-platform compatibility is a concern and a abstraction layer is indicated.
SVG is potentially more search-engine friendly and accessible than HTML5 <canvas>, in that SVG elements and text can be (potentially -- not sure if they actually do!) indexed and read out to a screenreader, user whilst <canvas> is initially just a bitmap and would need additional content to be created if one of these ads was to be presented as part of a web page. OTOH, if it's a game-like tool that's not for content creation then perhaps that's not an issue ... perhaps give more details?
I'm looking into writing my first HTML5 game, and everything I see talks about Canvas, and then goes on to talk about things like events, game loops, etc.
I'm planning on making a board game, where all the images are laid out on a grid. There doesn't need to be a game loop happening, because everything will just sit there just how it is until the user interacts with the game. And because the images for the board and pieces are laid out on a grid, I could just as easily (as far as I can tell) use tags, laid out with standard CSS, instead of drawing it all into a canvas element.
So is there a reason I should bother with canvas here? Does it make sense to just use "normal webpage" HTML elements to create my game interface?
Canvas is great for making games where things aren't a square, such as isometric or hexagon tile game, or an action based game where the player's sprite needs a wide range of movement, or something like Angry Birds where nothing is really grid based. For other things, it's probably overkill, though it might allow for quicker image processing and effects, due to being hardware accelerated in many modern browsers.
For what you're talking about, a grid based board game, it's perfectly fine to use normal HTML elements. If you're not going to need any fancy graphics effects, then you can safely ignore the canvas tag.
Side note: you could use canvas to make dynamic dice roll animations. It'd spice things up a bit, and give dice rolls an added 'suspense' effect. Or you could use 6 (or 12) animated gifs, just as easily.
There is a significant difference between html5 / css3 and a javascripted canvas tag.
HTML5 / CSS3
In this case you are just using the updated tags to present content, modified by some nifty css properties. You would then use "standard" js (and js frameworks) to control game logic and define user interactions and animations (or use CSS3 transitions to control any animation).
As you know, to create a couple rectangles:
div#red{
background-color:red;
height:50px;
width:50px;
position:relative;
}
div#blue{
background-color:blue;
height:50px;
width:50px;
position:relative;
}
<div id="red"></div>
<div id="blue"></div>
If you wanted to make this (unnecessarily) HTML5, they could be sections instead of divs. CSS3 definitely gives you a lot of nice new presentation features, specifically things like box-shadow.
Canvas
This is a fundamentally different way of working - much closer to something like Flash / Actionscript where content and presentation are defined programmatically, via javascript. For example - this is how you would create a similar couple of rectangles:
var canvas = document.getElementById("canvas");
function draw() {
var canvas = document.getElementById("canvas");
if (canvas.getContext) {
var ctx = canvas.getContext("2d");
ctx.fillStyle = "rgb(200,0,0)";
ctx.fillRect (10, 10, 55, 50);
ctx.fillStyle = "rgba(0, 0, 200, 0.5)";
ctx.fillRect (30, 30, 55, 50);
}
In a similar way, game logic and user interactions are defined. The flexibility and power of this later example cannot be overstated.
I say all of this simply to illustrate the fundamental difference in these two technologies. Now, IF you can do everything you want to do with markup, css and javascript behaviors, then by all means, do so. There is nothing wrong with this.
Working with the canvas tag, on the other hand, may give you increased flexibility and control over your project, allowing, for example, much more complicated and nuanced animations and interactions.
Finally, there are inherent issues with both of these routes, specifically, browser support. If you are targeting only the newest browsers, then I'm not sure it matters, but go back a couple generations and support drops off swiftly.
Then SVG is the right choice for you. Canvas is procedural, SVG is declarative and scalable. http://raphaeljs.com is a great framework.
If you want to create a game without further improvements you can do it without canvas. But using canvas gives you a lot of possibilities. Here are some of them:
All sprites appear in canvas, not in DOM. Adding/removing elements in DOM is quite difficult for browser; especially if you are going to use CSS-animation (for mobile platform). Animation on canvas is much lighter. It comes even more with "requestAnimationFrame" being developed now. It will greatly improve rendering speed.
You can apply different styles on canvas sprites and even change them dynamically. Canvas supports gradients. You can dynamically create sprites using "crop" operation on canvas area.
Scaling of all sprites on canvas can be performed by only one "scale" function. It can be really difficult to scale a game made of large amount of HMTL-tags.
It's easy to implement layer-based game field using canvas. It allows to control game elements with ease.
In our Enterra HTML5Poker - http://demo.enterra-poker.com/html5/index.html we use both canvas and HTML-tags to organize game field. We use common HTML-tags to organize lists, popup windows and interactive elements; and canvas is used to display game table, cards, avatars and other elements.
Using HTML5+JS as base technology for game development allows simple application porting to different mobile platforms. For example iPhone - http://itunes.apple.com/us/app/enterra-poker/id492214596, Android, Windows Phone and others.
I'm trying to make some web-based board games, and I want the interface to be pannable and zoomable. Much like how in Google Maps, you can pan and zoom the map, I want the game board to be moved and zoomed. Unlike Google Maps of course, I do not want to work with image tiles.
Can anyone give me recommendations as to what technology to use? Would this be a good fit for plain HTML? HTML 5 Canvas? or SVG? Any particular JS libraries to recommend or something else entirely?
I'd like to avoid flash and Java. And browser compatibility is plus, but not the most important factor. For example, I think it would probably be OK to require Chrome Frame for older IEs.
Any ideas/advice would be appreciated.
A few thoughts:
Use the OpenLayers UI with a "fixed" strategy to load vector graphics for your board all at once. (This is overly heavy-weight, probably, but comes with pan-zoom and IE compatibility.)
Use Raphael to build your board in SVG, using RaphaelZPD for pan-zoom. RaphaelZPD isn't cross-browser (even though Raphael is), so you'd need Chrome Frame for IE compatibility. This would be pretty lightweight, I think.
Use pure SVG for your board, use SVGpan for pan-zoom. Chrome Frame required here too, though you could use SVGweb if you wanted. You could draw your boards right in Inkscape, clean up the SVG's and add whatever ID's you need in the XML (SVG is XML under the hood), and interact with the board with jQuerySVG if you like, or script interaction by hand. Did I mention that CSS works with SVG? I think this is your best bet.
I can't think of an advantage to using Canvas here, unless you had lots of animation or bitmaps. SVG is far more transparent in how it works - it's XML under the hood, and when rendered in a page, becomes DOM nodes you can easily manipulate in modern browsers.
Plain HTML would probably be hard to handle scaling with. I've seen plenty of image scalers, but haven't seen complex HTML structures, and complexity would be compounded by needing to pan at a zoomed level.
If you want total control of your development environment you could create your own web rendering plataform. I think you can use HTML canvas 5 as your interface with the browser.
You can easily implement drag, pan and zoom using HTML canvas. This approach is very similar with game development in many plataforms. Here an example of using HTML canvas 5 for an interface that supports pan, drag, and zoom.
Having the control of your environment you will have a wide range of possibilities.
If you don't mind tiles, I'd suggest checking out Polymaps "A JavaScript library for image- and vector-tiled maps using SVG". It's probably possible to borrow some parts from there for panning and zooming.
I am a junior developer I can't understand how canvas tag is beneficial for us?
I read lot of articles on that but I can't get the root benefit getting from the canvas tag.
Think of the difference between canvas and svg as the difference betwee Photoshop and Illustrator (or Gimp and Inkscape for you OSS folks). One deals with bitmaps and the other vector art.
With canvas, since you are drawing in bitmap, you can smudge, blur, burn, dodge your images easily. But since it's bitmap you can't easily draw a line and then decide to reposition the line. You need to delete the old line and then draw a new line.
With svg, since you are drawing vectors, you can easily move, scale, rotate, reposition, flip your drawings. But since it's vectors you can't easily blur the edges according to line thickness or seamlessly meld a red circle into a blue square. You need to simulate blurring by drawing intermediate polygons between objects.
Sometimes their use case overlaps. Like a lot of people use canvas to do simple line drawings and keep track of the objects as data structures in javascript. But really, they both serve different purposes. If you try to implement general purpose vector drawing in pure javascript on top of canvas I doubt you'd be faster than using svg which is most likely implemented in C.
Basically, thanks to canvas, we can now draw/render 2D shapes using HTML5 and the canvas API.
As an example of what's possible now with canvas, see this
Some possible uses for Canvas:
Image drawing program
Photo editing/manipulation
2D Games
Advanced image viewing such as Microsoft's Deep Zoom
If you can't understand how it's beneficial, then maybe it isn't from your point of view at least. Don't think that because it's there I have to use it somehow, pick and choose what technologies work for you based on what you're trying to build, an Accounting web app probably wouldn't need a canvas for instance.
The canvas will enable you to draw pixel perfect graphics.
The cool projects that came to mind for me are:
Visualize gps data. GPS data is just an XML list of coordinates. You could easily build something in canvas to "connect the dots".
An mobile app where the user can actual sign a document with her finger - canvas allows you to export out the rendered canvas drawing to PNG where it can be saved on the server.
In a game where you have avatars, you can allow the user to actual draw on the avatar. Moustaches anyone?
Other stuff:
In iOS / Android using lots of CSS3
effects like box-shadow can lead to
poor performance, especially when
animating. You can do a lot of these
graphics in a single canvas tag,
here's an example:
http://everytimezone.com/. This thing is flawless on an ipad.
Cool background effects. For example try going to Paul Irish's
site and move your cursor around the
background: http://paulirish.com/
In this HTML5 book sponsored by Google a lot of the effects are using
canvas:
http://www.20thingsilearned.com/ -
particularly the "page flip"
animations.
my personal take on canvas (and when I actually found a use case for canvas) is the ability to color pick and color change per pixel in a canvas element - actually moving the image from something we don't have any information about what is happening inside it to an element like all other DOM elements (and yes, I know about the current problems with canvas and DOM - sure this would be taken care of in the future)
sure - canvas made some sort of animation easier and pluginless, but that we could do before (mostly with flash) - I think the real importance is the ability to know what is happening on the page.