I am just starting to learn about the canvas element, however I believe that it is double buffered.
Looking through the code for kineticjs It seems that the Kinetic.Stage creates two canvases (not in the DOM) a Kinetic.SceneCanvas and a Kinetic.hitCanvas. When you add a layer to the stage it seems to create 2 more canvases, another Scene and Hit canvas, one of which it displays in the DOM. Why does it need so many overlapping canvases? Or have I misread the code and/or missed the point?
Thanks
Take straight from the KineticJS GitHub Readme:
Kinetic stages are made up of user defined layers. Each layer has two canvas renderers, a scene renderer and a hit graph renderer. The scene renderer is what you can see, and the hit graph renderer is a special hidden canvas that's used for high performance event detection. Each layer can contain shapes, groups of shapes, or groups of other groups. The stage, layers, groups, and shapes are virtual nodes, similar to DOM nodes in an HTML page.
Additionally in the features section, KineticJS features:
High performance event detection via color map hashing
Related
while working on three js. I have a 3d model which has several small parts which are joint together to form a one three d loader (model). now I am using raycaster and intersects for finding out the clicked element. so its basically a door which has small screws, handles, hinges, bolts, rails, rotation points, pivots etc.
My problem is that while using raycaster and three js the element is not getting identified until or unless I zoom. when I zoom into a good extent I am able to identify clicked element. can anyone help me with that where I do get rid of zoom in.
You might be best to create an additional mesh attached/added to the small elements (like screws) - the additional mesh could be defined by a large sphere geometry shape that surrounds the screw. This larger sphere geometry would be invisible (ie its material visibility is false), and would function to intercept raycasting of the small elements like screws that are difficult to intercept on their own.
After reviewing the Kineticjs docs I have come up with the following
Kinetic.Node - Nodes are entities that can be transformed, layered, and have bound events.
Kinetic.Shape (Node) - Shapes are primitive objects such as rectangles, circles, text, lines, etc.
Kinetic.Container (Node) - Containers are used to contain nodes or other containers
Kinetic.Stage (Container(Node)) - A stage is used to contain multiple layers add(Layer)
Kinetic.Layer (Container(Node)) - Layers are tied to their own canvas element and are used to contain groups or shapes add(Node)
Kinetic.Group (Container(Node)) - Groups are used to contain shapes or other groups. add(Node)
Kinetic.BaseLayer (Container(Node)) - ???
Kinetic.FastLayer (Container(Node)) - is used for layers that don't need user interaction (update thanks markE)
Kinetic.Collection (Array) - This class is used in conjunction with Kinetic.Container#get
What are BaseLayer and 'FastLayer' used for exactly? In the documentation FastLayer has the exact same description as Layer and BaseLayer just says that it is a constructor.
in one of the commit comments it is inferred that FastLayer does not have to remove a hit canvas ... I am guessing this is because it does not have one thus making it faster?
Some clarification on what these two classes do, and how to effectively use them would be appreciated.
EDIT: Updated Question to reflect markE's input, anyone have insight on BaseLayer?
Note: as of this post the fast layer was introduced only several days ago. But as I understand...
The new fast layer is the old layer but with eventing turned off.
The KineticJS docs say:
If you don't need node nesting, mouse and touch interactions, or event
pub/sub, you should use FastLayer instead of Layer to create your
layers. It renders about 2x faster than normal layers.
The fast layer is used for layers that don't need user interaction:
a static background layer with no user interaction required.
a static layer that is manipulated and drawn entirely thru JS code with no user interaction required.
Drawing fast layers is faster because there is no overhead related to eventing.
Normal layers also have a supporting offscreen canvas which supports hit-testing and dragging.
I suspect the fast layer does not have this overhead either since hit-testing and dragging is related to eventing.
Having said this...I need to investigate this new tool more myself. ;-)
Question:
Is canvas more suitable than svg in the following case?
Case:
I'm drawing a chart (using d3js library) similar to this one (but with much more data):
http://mbostock.github.com/d3/talk/20111116/iris-parallel.html
It's based on an svg and it works fine for several thousands of lines (up to 5000), adding more lines (svg path) decreases the performance dramatically (scrolling in the page becomes slow)
Keep in mind: That I need to add mouse events (which is handy in svg)
Generally svg is better suited for vector images, like in your example. However canvas has a lot of benefits in modern browsers such as hardware acceleration, so for drawing the lines, as long as zooming, panning ect. isn't required performance will be using canvas.
Mouse events can be a pain using canvas, since you have to manually keep track of everything, so with 5000+ points using canvas it wont be fun. The trade off however will be once the points are drawn, assuming you only draw them once the page will behave fine regardless of the number of lines, since they are all drawn to a raster image and aren't part of the DOM.
Honestly though the best way to find it is to test what you currently have using canvas.
When performance becomes a problem, switching to canvas might be an option. In this case you can draw the canvas once. Afterwards it's pretty much treated like an image. Drawing might take some time, but afterwards it can be scaled pretty quickly. Note that it is possible to draw a rendered SVG to a canvas using the context.drawImage method (example). So you could keep your SVG generation code to create an SVG in the background, and then draw it to the canvas.
But keep in mind that it won't scale as beautiful as an SVG as soon as it is on the canvas. When the user zooms in, it will get blurry or pixely, depending on how the browser scales graphics.
Click events on canvas can be handled in two ways. Either keep an array of click targets, and add an onclick event handler to the canvas. When a click occurs, iterate the array and check which one is closest to the click coordinates.
The other option is to use hit regions. These have to be defined as polygonal paths.
+1 to everything said above. I've seen some amazing performance increases when using canvas over SVG and over compositing images using the DOM.
About manipulating the canvas image with mouse events, I imagine the best approach for an image such as you are describing is to abstract it away using a library like the following:
http://paperjs.org
http://kineticjs.com
http://www.createjs.com/#!/EaselJS
Keep your code away from the canvas itself and let a library do the thinking for you.
My project is using SVG and there is a plan to move out of SVG and replace the existing functionality with suitable replacement.
My current SVG apps does following things,
1. Exposes the object(SVG shapes) relations or dependency in screen.
When there are two dependent shapes (say rect1 and rect2), we draw a line from rect1 to react2 to say that they are dependent.
2. Triggers javascript functions when we fire certain events (click or mouse over) on shapes.
Is there any alternatives to replace the SVG and simply the drawing process?
I am thinking to store the shapes information in database and auto generate the shapes in UI.
Thanks in advance.
What about using canvas from HTML 5. Consider client browsers version when decide to use canvas.
I'm writing an app for shape manipulation, such that after creating simple shapes the user can create more complex ones by clipping the shapes against each other (i.e. combining two circles together into a figure 8 stored using a single path rather than a group, or performing intersection of two circles to create a "bite" mark), and am trying to decide on a graphics library to use.
SVG seems to handle 80% of the functionality I need out of the box (shape storage, movement, rotation, scaling). The problem is that the other 20% (using clipping to create a new set of complex polygons) seems impossible to achieve without recreating SVG functionality in my own modules (I'd have to store the shape once for drawing inside SVG, and once for processing clipping myself). I could be wrong about SVG, but by reading about Raphael library (based on SVG), it seems like it only handles clipping using a rectangle, and even that clipping is temporary (it only renders part of the shape, but still stores entire shape to be rerendered once the clipping rectangle is moved). Perhaps I'm just confused about SVG standard, but even retrieving/parsing the paths to compute a new path using subsets of previous paths seems non-obvious in SVG (there is a Subpath() function, but I don't see anything to find the points of intersection of two polygon perimeters, or combine several subpaths into a single path).
As a result, Canvas seems like a better alternative since it doesn't introduce the extra overhead by keeping track of shapes I'd already have to keep track of to make my own clipping implementation work. Not only that, I've already implemented the polygon class that can be moved, rotated, and scaled. Canvas has some other issues, however (I'd have to implement my own redraw method, which I'm sure will not be as efficient as SVG one that takes advantage of browser-specific frameworks in Chrome and Firefox; and I'd have to accept IE incompatibility which is handled for free with libraries like Raphael).
Thanks
This may address what you're mentioning.
Clipping can be done using non-rectangular objects using the 'clipPath' element.
For example, I have element with id of 'clipper' that defines what to clip out, and a path that is subject to the clipping. Not sure if they intersect in this snippet.
<g clip-rule="nonzero">
<clipPath id="clipper">
<ellipse rx="70" ry="95" clip-rule="evenodd"/>
</clipPath>
<!-- stuff to be clipped -->
<path clip-path="url(#clipper)" d="M-100 0 a100 50"/>
</g>
This is just a snippet from something I have. Hope it helps.
Seems to me that you are trying to do 2D constructive geometry. Since SVG runs in retained mode, the objects you draw are stored and then the various operations performed. With Canvas you are running against a bit map so the changes are effected immediately. Since your users will in turn perform more operations on your simpler shapes to create ever more complex ones Canvas should in the long term be a better fit.
The only outstanding question is what will be done with those objects once your users are finished with them. If you zoom the image it will get the jaggies. SVG will avoid that problem but you trade-off with greater complexity and performance impact.
Both svg and canvas are a vector graphical technology.Each one having some different functionality.
Canvas
Canvas is a bitmap with an immediate modegraphics application programming interface (API) for drawing on it. Canvas is a “fire and forget” model that renders its graphics directly to its bitmap and then subsequently has no sense of the shapes that were drawn; only the resulting bitmap stays around.
More Information about canvas - http://www.queryhome.com/51054/about-html5-canvas
SVG
SVG is used to describe Scalable Vector Graphics
SVG is known as a retained mode graphics model persisting in an in-memory model. Analogous to HTML, SVG builds an object model of elements, attributes, and styles. When the element appears in an HTML5 document, it behaves like an inline block and is part of the HTML document tree.
More Information about SVG - http://www.queryhome.com/50869/about-svg-part-1
See here for more information about canvas vs svg in detail - Comparing svg vs canvas
You're right - you'll have to mathematically perform the clipping and creation of new shapes regardless of whether you use SVG or Canvas. I'm biased, it seems like it would be more useful to use SVG since you also get things like DOM events on the shapes (mouse, dragging) and serialization into a graphical format for free.