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.
Related
What is the correct approach if you plan to implement a (complex, interactive) network diagramm in "HTML5", which is part of a modelling tool - for example to let the user design a workflow?
Is SVG the right approach or using directly Javascript/Canvas?. Is there any productive application out there, which has proved that this is doable in HTML5 (the network model can be quite complex), especially regarding performance?
I do not need any implementation details, just a hint to the 'correct' technology if you would be 'forced' to do this in HTML5...
Thanks.
svg now has support from ie9. canvas is supported in most modern browsers and css is supported by all.
svg has the advantage of beeing scalable (the 'image' is a vector map, so the user can have it in every size he prefers), but the performance of beeing rendered is a bit crappy. You can bind some events to the elements..
canvas is like GDLib or ImageMagick, you have a white sheet, where you can plot onto. So if you do a change, you first have to clear the canvas and redraw everything. You don't know onto what element a user has clicked onto and only can bind events generally for the whole canvas element.
Using HTML and the DOM with CSS would be an alternative, since you just could start moving elements of the network arround and can bind events to nodes of your network. But lines are quite hard to implement (can use a rotated div with top-border)
I personally would go for a hybrid between svg and plain html, but then again, I don't know every use-case of your application.
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 building a business application which mostly involves tables and other typical form elements. Due to the nature of my application however, I need to place groups of these elements together in a dynamic tree structure which will take up all of the available screen real estate. If real estate is low, there will be some form of smart scrolling allowing users to focus on certain areas of the tree. It could be called an advanced data visualization web form.
Historically, I would have accomplished this by simply using divs and javascript. The canvas element however seems like a more logical way to build my structure. Most uses of the canvas element that I can find are however geared towards graphics and animations (mostly games). Is canvas overkill for this? Will I benefit from using it? Are there alternatives?
Yes, canvas is overkill. It is very much a drawing board and not much more. It is certainly not something that I would expect to create user controls in. Games etc. are more suited as they aren't really standard user controls and wouldn't be expected to behave as such.
A tree structure could easily be implemented with a series of nested uls. Using some JavaScript to expand collapse them by adding and removing classes.
Here is a nice jQuery plugin for you to use or get some ideas of how you could use it.
Edit:
I would stay away from canvas just because of the overhead of the drawing. If you can extend a standard JavaScript treeview to add more functionality this would seem like the best option ot me. Creating controls from scratch in canvas is no small feat.
Edit2 (Post mockup):
This just looks like a multi-part form to me, with hidden forms/areas which are displayed as apropriately. This is far too common to require creating this with canvas.
Canvas is not fully supported in all browsers yet. I recommend using either Jquery or another framework.
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/
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.