1.) I found a canvas API called EaselJS, it does an amazing job of creating a display list for each elements you draw. They essentially become individually recognizable objects on the canvas (on one single canvas)
2.) Then I saw on http://simonsarris.com/ about this tutorial that can do drag and drop, it makes use of a hidden canvas concept for selection.
3.) And the third approach, a working approach, http://www.lucidchart.com/ , which is exactly what I'm trying to achieve, basically have every single shape on a different canvas, and use to position them. There's a huge amount of canvas.
The question is, what is the easiest way to achieve interactive network diagram as seen on http://www.lucidchart.com/
A side question is, is it better to get text input through positioning on canvas or using multiple canvas (one for rendering text) as in LucidChart
I'm the person who made the tutorials in 2. There's a lot going on here, so I'll try to explain a bit.
I use a hidden canvas for selection simply because it is easy to learn and will work for ANY kind of object (text, complex paths, rectangles, semi-transparent images). In the real diagramming library that I am writing, I don't do anything of the sort, instead I use a lot of math to determine selection. The hidden-canvas method is fine for less than 1000 objects, but eventually performance starts to suffer.
Lucidchart actually uses more than one canvas per object. And it doesn't just have them in memory, they are all there the DOM. This is an organizational choice on their part, a pretty weird one in my opinion. SVG might have made their work a lot easier if thats what they are going to do, as if seems they are doing a lot of footwork just to be able to emulate how SVG works a bit. There aren't too many good reasons to have so many canvases in the DOM if you can avoid it.
It seems to me that the advantage of them doing it that way is that if they have 10,000 objects, when you click, you only have to look at the one (small) canvas that is clicked for selection testing, instead of the entire canvas. So they did it to make their selection code a little shorter. I'd much rather only have one canvas in the DOM; their way seems needlessly messy. The point of canvas is to have a fast rendering surface instead of a thousand divs representing objects. But they just made a thousand canvases.
Anyway, to answer your question, the "easiest" way to achieve interactive network diagrams like lucidchart is to either use a library or use SVG (or an SVG library). Unfortunately there aren't too many yet. Getting all the functionality yourself in Canvas is hard but certainly doable, and will afford you better performance than SVG, especially if you plan on having more than 5,000 objects in your diagrams. Starting with EaselJS for now isn't too bad of an idea, though you'll probably find yourself modifying more and more of it as you get deeper into your project.
I am making one such interactive canvas diagramming library for Northwoods Software, but it won't be done for a few more months.
To answer the question that is sort-of in your title: The fastest method of doing interactiveness such as hit-testing is using math. Any high-performance canvas library with the features to support a lot of different types of objects will end up implementing functions like getNearestIntersectionPoint, getIntersectionsOnRect, pathContainsPoint, and so on.
As for your side question, it is my opinion that creating a text field on top of the canvas when a user wants to change text and then destroying it when the user is done entering text is the most intuitive-feeling way to get text input. Of course you need to make sure the field is positioned correctly over the text you are editing and that the font and font sizes are the same for a consistent feel.
Best of luck with your project. Let me know how it goes.
Using SVG (and maybe libraries as Raphael)!!
Then any element can receive mouse events.
Related
I'm working on a 2d world editor for html/js, and trying to find the best way to split up a chip set (as seen below) into multiple little squares (chips).
Currently, I'm using a method similar to the default css sprite sheets method, of using background position to move the background of many little <div> elements until each displays one square/chip of the chip set.
It is working fine, with no big performance issues, but it seems like an overall clunky way to do it.
Other ways I've thought of doing it would be to slice the chip set into many temporary images and make an <image> element for each, or using <canvas> instead of <div>'s or <image>'s
Anyways, I'm looking for advice on the subject:
What is a high performance way of splitting up Sprite Sheets/ Chip Sets in JS?
example of a chip set
The way you're doing it right now should be pretty fast. You could essentially reimplement that on the canvas level by storing just the one image then using drawImage to only draw sections from it. To the best of my knowledge, this is the most common way and is very fast. At least that was my experience when I wrote a game engine using canvas.
Using the canvas is most likely faster and more memory efficient since you don't have the additional DOM overhead but you'd have to measure it for your specific use case and verify that.
Creating a bunch of individual images, as you suggested, would be very slow since it'd require copying portions of the image and creating an additional DOM element for each image.
In short: using the canvas will always be faster (for a comparable implementation) since you're almost directly interfacing with the GPU. Drawing from one image rather than copying it into multiple sub images will always be faster since you won't have duplicate memory sitting around and as long as you're drawing from the same sheet, the GPU doesn't have to switch out the texture.
I am curious as to where to start to make something similar to HERE as I cannot find any information about it. It may be fairly simple and im sorry if it is.
What I am hoping to replicate is the colour grid that generates based on the colours and size of the lines. I am looking to replicate the functionality of the application whereby when the user selects a line and changes the width of that line and it will then calculate the image. I have been looking around but cannot find information about how to replicate it. I may be searching for the wrong thing as javascript is not my strongest language.
I know of a roundabout way to do it with svg but where would I start for javascript/jquery?
I know of a way to do it with svg but where would I start for javascript/jquery?
Well, SVG would involve javascript as well, wouldn't it? You're just looking for different ways to display an image. None is native the javascript, that is just a programming language, you'd have to consider which API to use:
There's nothing wrong with SVG! It even seems to be the easiest solution, maybe wrapping DOM code in some nice drawing library.
It has been demonstrated that such is possible with CSS3 background patterns, although I would consider this rather unusable
Use the <canvas> element! This would be the most genuine HTML5 approach, and even though the api is rather simple there exist mighty libraries.
I'd like to be able to write an application in HTML5 that is similar to the following.
HTML5 Canvas Animals on the Beach Game with KineticJS
The problem with that demo though is the mouse over event is only accurate to the rectangle surrounding the animal. Is there any way to do this with more accuracy, be it in KinectJS or otherwise?
There are generally two ways:
Using custom paths with each image as hitboxes (that you manually define) then using an is-point-in-path algorithm
Using a ghost-canvas (or whatever you like to call it) as I detailed in this old tutorial. Ignore the link to the new tutorial, the old one uses what you'd want.
The first method here is much faster but requires a lot more code and manual work. The second method is pixel-perfect but much slower. Still, if you don't have an enormous amount of objects it may suit your needs.
I am creating a dynamic, interactive network diagram with php, javascript and either Canvas or SVG
However, with canvas, I don't know how to make each object selectable. i don't want to use the hidden canvas and to detect if a mouse is on an object, because I will have lots of intersecting objects and having lots of layers of canvas will be messy.
I don't know anything about SVG.
Would SVG serves the purpose better? or what is a canvas solution to this.
One advantage of SVG is that it has concrete DOM objects representing the shapes in the drawing, so you automatically get a lot of mouse event handling and event bubbling.
Alternatively, you could use EaselJS, which provides a pretty robust display-list, freeing you from managing hidden canvases.
There are some projects for building diagrams and graphics already. You could try Raphaël which is svg based, so it should be ie compatible as well.
I assume by "the hidden canvas" you mean my tutorial. It will still work with multiple objects and multiple layers, you just need to paint them in the proper z-order.
There are of course much faster (but more sophisticated) ways.
If you don't want to deal with it, SVG has all the object selection built in. Give Raphael a try as Zlatev suggests. If the performance gets too bad (Too many objects) you will have to switch to canvas, so it really depends on your number of nodes/links in your diagrams.
You will have to take care of sending data to your server (in whatever way you prefer) yourself though. There's nothing built into SVG/Canvas/Raphael that will do it for you.
The 2nd part of the question is, which javascript library is better/easier to manipulate images with? I won't be actually drawing any shapes or anything. Other info: I'll be using jQuery and don't need to support all browsers, just webkit.
Edit:
More information: the current design is to layout/draw several rows/columns of images in a grid-like layout, with the image in the center being in "focus" (a little larger, with a border or something and some text next to it). The tricky thing is that we want the whole canvas of images to appear to slide/glide over to bring another random image into focus. So obviously the number of images in this grid needs to exceed what is visible in the viewport so that when the transition occurs there are always images occupying the canvas. Other than moving the images around, I won't be blurring them or otherwise modifying them. Eventually we will add user interactions like clicking/touching on a visible image to bring it to focus manually.
Let me know if this is not clear or still confusing.
I ran across scripty2 which seems like an alternative to using canvas/SVG for my purposes. I also started farting around with EaselJS last night, and it seems like this might work, but I'm wondering if it'll end up being more work/complex than just using standard HTML/CSS and a tool like Scripty2 to aid with animations and click/touch events. Just looking for any suggestions. Thanks!
The answer depends on your manipulation and animation.
If it's just translations, CSS wins for speed compared to canvas. I haven't tested, but I feel confident it easily beats SVG for the same sort of thing.
If you're going to be doing non-affine transformations or otherwise messing with the images (e.g. blurring them) you clearly want Canvas.
If you need event handlers per object, you clearly want a retained-mode drawing system like SVG or HTML+CSS. I haven't done enough CSS3 transforms to say how they compare in terms of speed to SVG, but they clearly do not have the robust transformation DOM of SVG.
This is a rather subjective question (or suite of questions) and you haven't yet given sufficient information for a clear answer to be possible.