I'm starting a new project using HTML5. Two of the most popular graphical toolkits are KineticJS and RaphaelJS. If you have experience of using these, do you have any advice? Which features do they offer, and is there an advantage in using one over the other?
E.g. only RaphaelJS works on legacy browsers (but this in not a feature I require).
The biggest difference between RaphaelJS and KineticJS is that RaphaelJS uses SVG and KineticJS uses HTML5 Canvas for visualization.
So it really depends on what kind of project you are doing.
Here are some useful links which you should check out regarding SVG vs Canvas:
Thoughts on when to use Canvas and SVG (also describes a hybrid approach)
Simon Sarris excellent reply in this stackoverflow thread (I also posted some benchmarks between SVG and canvas in the same thread)
To summarize:
If you want to create some interactive charts I would go with RaphaelJS because it's easier to do that with SVG (KineticJS does provide some abstract API which should make it fairly easy to do that too).
If you want to visualize huge numbers of shapes/objects I would recommend to use KineticJS as canvas scales usually better with huge numbers of shapes/objects to be drawn and KineticJS uses multiple layers to improve rendering performance.
Related
As I am building my simulator using createljs, I will need to have thousands of little circles ( 3 pixels diameter ).
I can draw a circle on a shape graph, is this a recommended approach? or shall I use a bitmap?
Any idea about the best way in terms of performance?
Also, is it possible to set text antialias on or off?
You can check the following article to read about optimizing the canvas.
http://www.html5rocks.com/en/tutorials/canvas/performance/
In this paper, we show different rendering techniques with canvas
About easeljs adobe has a guide for developers who are transitioning from AS3 to HTML5:
http://blogs.adobe.com/digitalmedia/2011/01/getting-started-with-the-canvas-element-and-easeljs/
In this article shows how to create a new Shape instance from a previous object definition.
If you are looking for performance, consider caching your shapes using Shape.cache(x,y,w,h), which provides some benefits in most browsers. Check out the cache demo that is in the EaselJS Git repo. Note that Safari 6 has the opposite effect (caching is slower) in that example because Safari does awesome optimizations on Graphics already, and handles lots of small objects on the GPU poorly.
If you shapes change a lot over time, then caching may not be a good option.
What would you say, using canvas or webGL?
I have read somewhere that canvas isn't very performant, because currently it's based on the DOM, or something like that. On the other side webGL isn't well supported yet. And it's also more difficult to learn I guess.
The game is "2.5"D - it doesn't need 3D. But wegGL could make sense for good effects and because it's processed in the graphics card. The fact that it is not well supported across browsers is something I could live with, if I see it really offers advantages (performance, effects, etc.) which I couldn't get using canvas.
I don't mind about steeper learning curve. What is important is that the game is well scalable, performs well at the end, and that most features are potentially possible.
Hope to get some good opinions, thanks in advance!
2D Canvas will do you well here.
The math will be far easier than using WebGL and 2D Canvas is now hardware accelerated on every major desktop browser and enjoys wider support on mobile devices than WebGL.
Canvas is not slow because its a DOM element, ideally the only time you touch the DOM is when you get the context. Touching the DOM, for the record, is always slow but you only have to do it that one time.
There are a few tutorials about isometric canvas games as well as some good questions here on StackOverflow asked by Neurofluxation, but he deleted most of the relevant code from his questions for some reason, which is a bit of a shame.
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?
What I need to do is create a simple preview of a minecraft "dude" with the correct texture applied.
I'm not concerned with complex animations (yet) or detailed lighting (yet) but I'd like to make it using canvas and not rely on WebGL(not really that widely supported yet).
What technologies would you recommend for this set of limitations?
Ah, also, I don't need to edit or save the skin or whatever, just a simple display.
THREE.js is a popular javascript 3D library, it supports both canvas and WebGL
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.