As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm creating an HTML 5 chess game. Server side is socket.io / node.js / backbone.js.
I'm now beginning to write the view for the game board. Would it be easier to represent a chess board in canvas or DOM elements (aka divs)? Disregard browser compatibility.
Really comes down to your motives.
If you know game developement well, and you're comfortable with dividing screens into segments for purposes of collision-detection or otherwise, and you can easily create your own custom click events, per square/unit, based on where on the canvas the player clicked, then go with the canvas, as you'll open more doors to advanced animations and graphical-interactions that way.
If you aren't comfortable with that, and would like a straightforward way of knowing which square was clicked, and would like a clean-cut way of knowing if there was a unit in the square you landed on, without having to figure it out based on the X and Y where you clicked inside the game window, then go with the DOM -- really, those are the benefits and most everything else is a side-effect of picking one or the other.
Canvas for animation and "polish", DOM for event-listeners and array-based (or attribute-based) notification of square clicked.
For what you're planning to do, I think DOM would be the best option. Not because Canvas has any drawbacks, but for just based on the amount of work you'd need to be done, and the ability to change how the board looks easily.
You can use divs and place them absolutely, add css styles to show/hide pieces on a certain square, and after all that, you can even make a large background-less canvas and draw special effects on top of the DOM based chess board.
So all in all, DOM should be the way to go for you.
It depends on your goals.
If your main interest is just to visualize the state of the game by rendering icons for the pieces as images then using the DOM (e.g. tables or divs) for board locations is probably easiest.
If your are more interested in advanced graphicals then canvas might be better.
I've developed one of those quite recently and used HTML5 Canvas for graphical interface. It was extremely powerful for drawing the board and moving the pieces.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I'm a beginner in web animations(canvas and svg). I have seen some work and examples in Chrome Experiments and am really excited to dive in. However, whenever I'm trying to do anything remotely decent or following any tutorial that seems a little bit interesting, the sheer amount javascript that has to be put in is proving to be a huge turn off.
For example, if I want to do any simple svg animation, I have to manually place the co-ordinates to achieve the effects. If there were any GUI tool to work with SVG or Canvas that would produce the initial movements(i.e. If I want to move an object from A to B, I'd like to do it by hand rather than counting the pixels) then the subsequent tweaking would be a lot easier. Are there any tools that help you achieve the effects? If not, what's the standard way to draw and animate svg graphics/canvas animation today?
Hype, Sencha Animator , Adobe Edge Animate are tool you might want to use if your purpose is to do animation with web technologies.
The problem with the link you provided is many of the exemples involve quite a lot of programming. It's not like Flash where you could do crazy stuffs with little programming knowledge. So you are not going to do crazy stuffs with any of the program I cited. By the way flash now exports to web techs so you might want to look into that.
You will have to write some javascript to make a decent animation with Canvas or SVG, as most of the previous software work with the DOM.
But you can cheat, a lot of agencies now use video (from After Effect) for animation directy, and you can manipulate video through canvas, do compositing etc ... the problem will be the size in that case.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What solutions other than HTML5 canvas can be used to implement free-hand drawing in JavaScript?
I have tried using HTML5 canvas but it did not work out as i was having problem in saving the canvas along with the text. Moreover the canvas can only be saved as image. But i need to save it in a format in which i can open and again draw and edit text.
UPDATE:
Now after you added more info to your question I know why you don't want to use canvas (which you still can use, but in a different way that you did before, but you may prefer another approach for you application - see below). People have voted to close your answer and it means that no new answer can be posted until it is reopened so I'll try update my answer. I have also voted to reopen your question.
Drawing in JavaScript Options
For free-hand drawing in HTML you have only 3 options:
Canvas
SVG (VML on IE)
Plugins (eg. Flash, Java, Silverlight)
You didn't explain why you don't want to use canvas.
Browser support
If the browser that you need to target doesn't support Canvas then you can:
use SVG or VML (or a library that uses SVG/VML like Raphaël)
use something that implements canvas (eg. in Flash) like:
http://code.google.com/p/fxcanvas/
http://flashcanvas.net/
http://excanvas.sourceforge.net/
API
If the native Canvas API doesn't suit your needs then you can use some canvas library that provides more functionality or a better API.
Here are some quick links to get you started:
http://dmitrybaranovskiy.github.io/raphael/
http://processingjs.org/
http://kineticjs.com/ (No longer maintained!)
http://www.createjs.com/#!/EaselJS
http://paperjs.org/
http://www.bhivecanvas.com/
http://fabricjs.com/
Retained Mode vs. Immediate Mode
What you need is a retained mode rendering (as opposed to immediate mode).
Canvas is an example of an immediate mode rendering while SVG/VML work in retained mode. It means that once you draw something on canvas it's just pixels and you can't manipulate objects that were drawn or save anything other than a flat raster image. SVG on the other hand keeps the entire DOM of the objects that you draw (just like in HTML) and you can easily manipulate everything that you have there, attach events, change colors, fill styles, move things after they were drawn or saved etc.
You can still use Canvas to do what you want but you need some library to help you keep track of everything that is being drawn - a library that provides a retained mode as an abstraction layer on top of the immediate mode Canvas API - some of the libraries that I previously described work that way, see the links above - but still you may find another approach better suited for your needs.
A Ready Solution
Take a look as the SVG-edit (or on GitHub) project - and especially see the demo and other projects that use SVG-edit. Using SVG-edit would probably be the easiest way to achieve your goals.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am creating a piano roll like interface, one like you might find in a DAW such as ableton, that looks something like this http://www.abletonlife.com/wp-content/uploads/2010/04/midi-track-big.jpg . The grid represents a canvas to draw in notes to be played, the red squares being the notes to play. You double click on an empty space to create a new note, and you can drag the edges to change the length of the note.
I am new to web dev so I am having a bit of trouble seeing what the right architecture for this might be. With my limited knowledge, the following are the architectures I can think of.
1) Rows of horizontal flex-boxes.
display: box;
box-orient: horizontal;
box-flex: 1;
Something like this, http://jsfiddle.net/ZgzNw/.
Pros:
When resizing the browser window, the browser will automatically
handle resizing of the notes and therefore the grid. Resizing of divs/notes also handled easily for zooming in and out and changing quantization values.
All notes in all positions already exist, when double clicking to "create" a new note, all you have to do is change the css for that note (to be red) etc.
Cons:
Since there is a div for every space in the grid, even empty spaces where there is no note to be played, there will be a lot of divs. Can the browser handle thousands of divs? As an extreme example if there is a 32nd note quantization, a song of 200BPM would have 50 measures per minute, take a 10 minutes song, that would be 500 measures. Going back to the jsfiddle example above and setting measures=500 and quant=32, I get the following error in the Chrome Developer tools console after a few seconds "Uncaught RangeError: Maximum call stack size exceeded". This is when creating the divs in that bit of javascript, If I lower the number to around 300 it is able to create the divs, but things become laggy.
2) Create the grid using divs of width=1px for the vertical lines of the grid. Create new note divs on the fly, position them manually (with position: float?) based on the position of the mouse click.
Pros:
Only have a divs for actual note that are on, so don't have the con of method 1) being an issue
Cons:
Have to manually compute everything, Where to place newly created note, zooming in/out means repositioning vertical markers for grids, and calculating new sizes for note divs. This was mostly handled automatically in the method 1.
I'm sure there are a lot more architectures and pros/cons to the two methods I describe, but I've never created any web applications and the extent of my web-dev experience is the tutorials I've done over the last 2 weeks to teach myself.
My question I guess is what is the best architecture for creating this piano roll interface I am describing? Specifically the UI representation, not the backing model.
I would create a simple model (probably just a multi-dimensional array) to contain the representation of the score, where each array item represented a note at a point in time. From the model, you can then draw/redraw accordingly. You could also perform operations like time shifts, quantizing, thinning, etc. by modifying the arrays.
Can the browser handle thousands of divs?
A few thousand, yes, maybe more--maybe even a lot more--but results will greatly vary by browser, by computer, even by the way they are positioned (floats tend to be slower than absolute positioning, for example, because the browser has more to calculate).
Instead, I would research using a canvas and draw/redraw based on your underlying model. You can detect events on the whole canvas, and depending on coordinates, easily map the event to the note(s) to which it corresponds.
KineticJS has some cool examples using a canvas
I would use a background image to represent tracks and measures, and one div for each note. It is not necessary to keep all notes as div’s in the browser, it would work better only to have the div’s for the visible up to 10 measures.
Imho, this should be done fixed-width, and there should not be any resizing of the piano roll at all. So you can use calculation of pixels. I don’t think this will work without making use of Javascript heavily.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Does html5 help developers animate vector graphics in any way? I'm talking about straight key-frame vector animation, such as what flash does.
Is the way to do this basically using javascript to manipulate SVG graphics (such as what http://www.raphaeljs.com does? which is a bit weird to me since it's been supported in browsers for quite some time) or does html5/canvas lend itself someway to vector graphics animation?
I'm just trying to understand what's the "new" way developers will animate vectors on the web if/when flash plug-in eventually dies.
Thanks
There's also CSS animation, which is declarative and can be more efficient because the JavaScript code is not pushing the animation.
But there's nothing inherently wrong with the SVG approach and it's more compatible as well.
Currently there is no alternative for complex animations like the animations you can create with Flash (eg. shape-tweens or animations with 3d or bones), and I personally I think Flash is the way to go if you want crossbrowser killer animation. The Flash IDE offers lots of animation features which are not implemented in any other current web based tool. HTML/css is very limited, since it does not fully support skew/rotation/perspective in all browsers and in HTML you cannot animate background images too. However you can create programmatic tweens (like motion-tweens) with Javascript. At this state of HTML you must be a bit hardcore programmer to get a serious DHTML animation and I think you have to deal with CSS sprites or other blitting techniques to get some performance. Beside animation, Flash offers filtering and blendmodes too, which you would like to use in great animations too.
You can use the animate() function from jQuery for very simple animations (move, fade, slide); you can change properties over time. For a lot of web applications; this could enough. But if you want to animate vectors or want frame based animations; Flash is currently the best choice.
PS. What is wrong with animated GIF's?
This might be interesting in the future. It is a flash to Html5 conversion tool form Adobe. Maybe there is a future on the web where the two technologies converge to a single purpose in stead of being two concurrent technologies side by side.
We may well agree that flash has some drawbacks, closed, slow technology. But I can not believe there is no knowledge in the flash source code, its developers and the large amount of users that could be helpful in the development of Html5. Flash is an easy to use environment for creating animations. Such an environment just does not exist for Html 5. So I believe there is room for flash and Html 5 together.
Edit
You should check out Adobe Edge Preview. a new tool from Adobe for creating rich HTML5 animations.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are advantages and disadvantages of creating games in 'pure' DOM as compared to using canvas?
canvas
pros :
could manipulate pixel and apply filter effect, so easy for image processing;
very efficient for small size but hundreds of elements in the game
many libraries for game could be found using canvas, such as box2dweb, and could make awesome games such as angry bird
cons:
it's stateless, so you have to record the states of the elements in the canvas, and handle the hit test by yourself.
low efficient for very large size but with one a few elements in the game
great ability, great responsibility. the freedom to draw, brings in you have to charge of all the drawing staff. Fortunately, there are many libraries there, such as cocos2d-html5, IvanK.
DOM
pros:
rendering by the browser, so less error-prone;
cons:
could do simple animation with CSS only, that makes the game not fluent;
no good for manipulating hundreds of DOM elements;
When you develop with Canvas you will have to use the GameLoop technique which is very painful because you will have to redraw all elements all the time.
When you develop with DOM you will be able to redraw only the objects that have been modified and will leave the hard work for the browser implementation.
If your game has a few modifications per frame then you can use the DOM, otherwise use the Canvas, please! It is so much faster!
With canvas you can perform operations such as rotation that you can't do with pure dome without use some "heavy" tricks. Anyway the dom is faster and you can use it in every browser without problems. You must think about what are you going to use in the game, if you will use only basic operations use the dom otherwise choose the canvas.
Look here: Why Canvas is not an obvious choice for web games.