I need the ability to efficiently draw a large number of interactive curves (possibly Bezier) in a web app. Imagine a graph-like structure with many draggable elements that are connected with smooth curves. Hence, the curves must adjust in shape and length as single elements are moved.
What graphic method will be best to assure efficiency and interactivity for a large number curves?
SVG? Canvas? something else?
(And once we know which method is best, is there a good library that would make it easier to implement?)
You might take a look at JSXGraph. I haven't personally used it, but know some who has with nice results. It looks like it will use 'SVG, VML or canvas'.
Related
I've made a program that creates parametric shapes (spheres, toruses, and cylinders) and performs matrix transformations on them to animate them in specific ways (e.g. translate(), rotate(), scale()). I now want to animate the shapes using splines which will serve to allow the shapes to move along smoother paths than with the transformations alone. I'm not exactly sure how to approach this with html5 and javascript, but based on my work up to this point, I would think that the approach would involve first calculating all of the points that lie along the spline curve (for x,y, and z), storing each point in a data structure, and then iterating over the data structure passing in each point to the translate() method.
I've looked at some resources on B-Splines and NURB's but sites like these generally seem either very theoretical and hard to translate to code, or they use specific api's in languages that I'm not using. What would be the best implementation (code wise) of this sort of spline animation in html5 and javascript?
I'm planning to commission a developer to help me create a simple mathematical art piece. I'm wondering if the following can be accomplished with JavaScript vector art, and if not, what approach you would recommend.
The image will start off with some intersecting lines forming a shape. This is essentially an image zoomed in 1000% or more, and the user can scroll to zoom out until the full image fits the width of the screen.
Naturally, an actual image of this size would be huge, so I'm thinking it would be better to draw it programmatically, which might also enable the line thickness to scale up a bit as you zoom out, so that they're not nearly invisible when zoomed all the way out. The image can not look pixellated when zoomed all the way in, but achieving this with some “trickery” like swapping out images is also ok.
Example:
Basically the reverse of zoom.it but at a significantly larger scale.
http://zoom.it/
Some libraries I've looked at are:
paper.js
fabric.js
leaflet.js
raphael.js
How can an extreme zoomout like this be accomplished?
You are definitely on the right track. I think what you want is very possible on the web using HTML5. You are correct in that the easiest/best performing implementation of this would be using vector graphics. You can use image tiles, however the preprocessing and bandwidth requirements for tiling get large very quickly.
Here are some of my thoughts from working with some of the libraries you listed:
Leaflet.js - Leaflet supports both drawing SVG elements as well as image tiling (if you wanted to go that approach). Leaflet is also "mobile first" in that it supports things such as pinch zooming and double tap to zoom out of the box. Scroll zooming is also supported out of the box. Getting something up and going with Leaflet is simple. As far as I know Leaflet is writing SVG to the DOM; which is something to keep in mind.
Raphael - Raphael is capable of what you want, however you may need to implement zooming aspects yourself. This is definitely possible to do and shouldn't be too difficult, but something to keep in mind. Raphael will write SVG elements to the DOM; which can get a bit unruly if you have many many SVG elements. However, you may be able to optimize this and create/destroy elements as you are zooming.
Paper and Fabric - These both appear to render SVG to Canvas (different than writing SVG to the DOM). These both look really powerful, and seem to have good APIs for zooming. You would likely still need to hook up scroll/touch gestures to get zooming to work the way you want. These both should perform very well as they are using lower level APIs which should bypass many issues you might have with doing this in the DOM.
I am writing a web visualization tool which involves displaying a processed image ~30 times a second.
I have been using the standard canvas tag and using functions such as getImageData/putImageData to perform some pixel manipulation along with drawing circles, squares and paths using beginPath() and bezierCurveTo(), stroke(), etc
Everything is working great but I am getting horrible performance even with hardware acceleration.
Is canvas inherently slow at these types of operations?
I have been researching into using WebGL/THREE.JS for performance, but all I need is to do pixel manipulation with some basic shape drawing. Is WebGL overkill for this? Is there a better alternative?
Ideally I believe I want something that wraps the canvas API but displays it using the WebGLRenderer for performance.
I want to build a simple modelviewer. In fact that most 3D Engines for javascript/canvas out there are way too complex for my purpose I'd prefer building a small one on my own. By writing a z-buffer I'd like to check wether canvas API should draw a pixel over the existing image. At the moment I am using the method fill() to draw triangles. I do so because I'd like to avoid writing my own anti-aliasing stuff. Are there any callbacks or is there any other way I can implement my check into the native script?
In fact that's going to be in Adobe AIR, are there any native ressources I could use to speed up(molehill/Stage3D WebGL? Dunno). Or are there any ways in combination of Flash? Actually I'd prefer Javascript but if there are native solutions I'd also like to check them as long as I can implemenet them into my HTML mock-up.
EDIT: A more simply question: Is it possible to implement a check for each pixel the canvas API should draw to abort drawing the pixel if it doesn't fit some conditions? I don't think that the chance is high that the question becomes affirmed but its really woth it.
I need to choose a library for "standard" charting: pies, lines and bars.
From what I've read, it seems to me that the best format is SVG/VML, like Highcharts for example. SVG is becoming standard across all major browsers, now that IE 9 accepts it. It seems easier to rescale and export than Canvas.
Still, I see that several charting libraries rely on Canvas. Am I missing something? Is there any reason for considering Canvas over SVG for such applications?
You can generally achieve the same results with either. Both end up drawing pixels to the screen for the user. The major differentiators are that HTML5 Canvas gives you pixel-level control over the results (both reading and writing), while SVG is a retained-mode graphics API that makes it very easy to handle events or manipulate the artwork with JavaScript or SMIL Animation and have all redrawing taken care of for you.
In general, I'd suggest using HTML5 Canvas if you:
need pixel-level control over effects (e.g. blurring or blending)
have a very large number of data points that will be presented once (and perhaps panned), but are otherwise static
Use SVG if you:
want complex objects drawn on the screen to be associated with events (e.g. move over a data point to see a tooltip)
want the result to print well at high resolution
need to animate the shapes of various graph parts independently
will be including text in your output that you want to be indexed by search engines
want to use XML and/or XSLT to produce the output
Canvas isn't needed unless you want heavy manipulation/animation or are going to have 10,000+ charts. More on performance analysis here.
It is also important to make the distinction: Charting and diagramming are two different things. Displaying a few bar charts is very different from (for instance) making diagramming flowcharts with 10,000+ movable, link-able, potentially-animated objects.
Every SVG element is a DOM element, and adding 10,000 or 100,000 nodes to the DOM causes incredible slowdown. But adding that many elements to Canvas is entirely doable, and can be quite fast.
In case it may have confused you: RaphaelJS (in my opinion the best charting SVG Library) makes use of the word canvas, but that is no way related to the HTML <canvas> element.
In the past two years, my preference has been to use svg, as I mainly deal with relatively small datasets to build pies, column charts or maps.
However one advantage I have found with canvas is the ability to save the chart as an image thanks to the toDataURL method. I haven't found an equivalent for svg, and it seems that the best way to save an svg chart client side is to convert it to canvas first (using for example canvg).