So I'm just getting into SVG and learning how it works. At the moment I am creating a project that involves rotating several SVG <circle>s at different speeds, thus learning how animateTransform works.
However, I found out that one can use CSS3 animations (which I am much more familiar with) on SVG objects. I realize that animateTransform can do more complex animations, but I'm talking in terms of a simple animation that both options have the capability of completing.
What are the drawbacks (if any) of CSS3 animations used on SVG objects when compared to animateTransform? Does animateTransform perform better?
No IE support for <animate… you have to use a polyfill library like fakeSMIL - which is not the end of the world. Also css3 transforms are GPU accelerated on iOS mobile and chrome for mobile (for the most part) so they tend to be smoother.
Related
Is there any known implementation of a 2D canvas fallback for the awesome playcanvas game engine?
The idea is that the system should test rendering performance during the loading process in WebGL vs Canvas 2D, and fall back to Canvas 2D in case it finds better performance there o in cas WebGL is not supporte in the browser.
Other frameworks three.js or pixijs have this feature and it would be great for playcanvas, but as long as I have seen they do not have this feature and no solution have been implemented by the community.
No, there is no Canvas 2D fallback for PlayCanvas.
First of all, Canvas 2D will never be faster than WebGL for rendering 3D scenes. This is because you would have to shift complex GPU tasks onto the CPU. PlayCanvas implements a very sophisticated physical rendering pipeline and reimplementing it CPU-side will never give acceptable performance. It makes more sense for Pixi because Pixi is largely concerned with 2D sprite primitives which can be rendered quite cheaply by Canvas 2D.
At the time of writing, WebGL has a penetration of 91.1% and the trend is still upwards. Therefore, you have a relatively small minority of people who can't experience WebGL right now.
In the situation where the user can't run WebGL (for whatever reason, such as running IE9 and below), the recommendation would be to simply display a message asking to upgrade to a WebGL-capable browser.
This fallback to canvas if no webgl is a very fringe feature and perhaps that is why there is little desire to implement it. Perhaps it was useful before when webgl support is extremely limited but I dont see much need for it atm. Heres why:
If canvas api met all your requirements, then there is little point in writing a webgl app to do the same thing as the canvas api.
If webgl features are desired/required, such as 3D, or simply need to draw many sprites with different scale/rotations, then canvas performance is likely not up to par. Furthermore, browsers (last time I checked) have very inconsistent canvas performance. It was what motivated me to write a webgl renderer in the first place.
Assuming that the SVG is the standard for still vector images, there is an equivalent for animated vector-based images too ?
The problem I'm trying to solve can't be solved by pixel-based formats such as APNG or GIF, they don't scale at all on different displays, and they also get really really heavy pretty quick, vector images are what I need but I need a standard way to provide a file with an animated vector entities in it.
To be clear I'm not trying to animate a webpage or part of it, I'm asking for a filetype or standard that is good for just this task.
You can animate SVG graphics... they don't have to be static. That said, SVG is the only vector graphics format the web supports (natively) so I guess the answer is SVG! ;-)
The SVG specification includes SMIL as an animation mechanism. IE9/10/11 do not support SMIL, although other UAs do. There's a javascript library called fakesmile that can enable SMIL on UAs for which support is lacking.
There's also CSS animations which IE does support, although overall support for CSS animations is somewhat less complete in most UAs.
I found Famo.us and it seemed pretty exciting but their docs are closed. I am very curios about WebGL so I started looking for alternatives. I found Three.js and Clara.io.
How do they differ from famo.us? What is the main objective of each framework?
Thanks.
Edit: Rephrased.
Three.js is a lightweight javascript library to create 3D visualisations (using WebGL, SVG, Canvas or another renderer).
Clara.io is an online 3D modelling tool using WebGL.
Famo.us is a javascript rendering engine to create web-apps with 3D user interfaces that promises to run smooth (60FPS) on mobile devices.
Famo.us claims to solve the HTML5 performance issue by avoiding DOM-layout and repaints, which are very expensive computations. Instead, Famo.us keeps a flat DOM and uses CSS3 transforms for all layout and positioning. Unlike the others you mentioned, Famo.us does not render using WebGL (yet), as Safari does not have this enabled by default.
Famo.us includes a physics engine to provide realistic and complex user interaction (e.g. bounce on a scrollview, 3D coverflow, that sorts of stuff). In Famous, you construct a scene-graph and add animations, events and physics to make everything come alive.
http://Clara.io is an online 3D modeling, rendering and publishing platform that can import and export in standard formats. It uses ThreeJS/WebGL and it imports and exports in the ThreeJS format as well.
Although Clara.io is not intended for creating applicatipns, you can also easily make interactive experiences Clara.io such as this demo by Klaas:
https://exocortex.github.io/klaas
I'm in the process of starting to build a strategy game (think warcraft) for the web. I've been doing research on HTML5 Canvas and CSS3 sprites and still can't decide which technology to use.
The game won't be completed for another 6 months.
Any advice would be appreciated.
As you probably hear so frequently... "It Depends..." ™
My suggestion would be consider the feel of the application you're after. If you are trying to build a very graphically rich, mostly-images application, then I would use Canvas. However if you are trying to animate some graphics, but have the page remain and behave more "Web-like", mixed with other HTML content, I'd give CSS3 a try.
Two additional points:
Currently, Canvas is better supported than CSS3 animation/sprites.
If you use Canvas you're going to be implementing your own render loop and animation code (or making use of a 3rd partly library). Your code create animation by compositing the various layers of each frame, applying movement, and repeating. You can't simply say "move this image a little to the right". You'll have to do that yourself.
The EA web game "Lords of Ultima", as dull as it is, is an excellent example of a WarCraft-styled (well, it's more city building as there are no visible units) overworld, with animations and everything, built on a pure HTML and CSS sprite base. It looks and performs well and I think the square block box-model nature of HTML suits that kind of tile based design, especially since a lot of the image processing (embed an <img> or a <div> with a background, change background-position for animation) and click/mouse handling is done for you in simple html.
If you do go canvas you have to manage that yourself which will greatly increase the complexity and dev time. You'll have more control of minor elements and improved performance, but then you'll also lose (if it's at all important), greater backwards compatibility with older browsers. So it depends on how complex your design is and what kind of performance you need.
Use Canvas. If you use CSS sprites to build a game, then you are going to make a lots of <div>'s which performs operations on the DOM, which may slow down and also have a lots of focus and compatibility problems.
It may pay off to trade the development time for performance on <canvas>, by the assumption of "A code will be maintained forever".
I think CSS3 sprite system takes more time to develop, because you need to handle browser compatibility.
Browsers like IE 8 (8 or 9?) are using GPU to accelerate graphics, which lets you get the free lunch of Moore's Law.
There's pros and cons to both. Currently, Canvas is better supported then is CSS3, but you said that your game won't be done for another 6 months, by then the support for CSS3 could be much much better. There's also a lot of other variables here, such as: What browser will the game be viewed on? How advanced are the graphics you need to animate? etc... I would say that canvas would be better for support of the current generation of browsers and for gaming graphics, however CSS3 would be quicker, but wouldn't even come close to the support or graphics handling. But it doesn't seem like your in a rush to get it done.
Basically:
Canvas: Graphics, current support in users browser
CSS3: Speed of development
Ether will work. But for now I would use Canvas. However, 6 months in the tech world is an eternity, things could be a lot different then.
I'm planning on writing a game using javascript / canvas and I just had 1 question: What kind of performance considerations should I think about in regards to loading images vs just drawing using canvas' methods. Because my game will be using very simple geometry for the art (circles, squares, lines), either method will be easy to use. I also plan to implement a simple particle engine in the game, so I want to be able to draw lots of small objects without much of a performance hit.
Thoughts?
If you're drawing simple shapes with solid fills then drawing them procedurally is the best method for you.
If you're drawing more detailed entities with strokes, gradient fills and other performance sensitive make-up you'd be better off using image sprites. Generating graphics procedurally is not always efficient.
It is possible to get away with a mix of both. Draw graphical entities procedurally on the canvas once as your application starts up. After that you can reuse the same sprites by painting copies of them instead of generating the same drop-shadow, gradient and strokes repeatedly.
If you do choose to draw sprites you should read some of the tips and optimization techniques on this thread.
My personal suggestion is to just draw shapes. I've learned that if you're going to use images instead, then the more you use the slower things get, and the more likely you'll end up needing to do off-screen rendering.
This article discusses the subject and has several tests to benchmark the differences.
Conculsions
In brief — Canvas likes small size of canvas and DOM likes working with few elements (although DOM in Firefox is so slow that it's not always true).
And if you are planing to use particles I thought that you might want to take a look to Doodle-js.
Image loading out of the cache is faster than generating it / loading it from the original resource. But then you have to preload the images, so they get into the cache.
It really depends on the type of graphics you'll use, so I suggest you implement the easiest solution and solve the performance problems as they appear.
Generally I would expect copying a bitmap (drawing an image) to get faster compared to recreating it from primitives, as the complexity of the image gets higher.
That is drawing a couple of squares per scene should need about the same time using either method, but a complex image will be faster to copy from a bitmap.
As with most gaming considerations, you may want to look at what you need to do, and use a mixture of both.
For example, if you are using a background image, then loading the bitmap makes sense, especially if you will crop it to fit in the canvas, but if you are making something that is dynamic then you will need to using the drawing API.
If you target IE9 and FF4, for example, then on Windows you should get some good performance from drawing as they are taking advantage of the graphics card, but, for more general browsers you will want to perhaps look at using sprites, which will either be images you draw as part of the initialization and move, or load bitmapped images.
It would help to know what type of game you are looking at, how dynamic the graphics will need to be, how large the bitmapped images would be, what type of framerate you are hoping for.
The landscape is changing with each browser release. I suggest following the HTML5 Games initiative that Facebook has started, and the jsGameBench test suite. They cover a wide range of approaches from Canvas to DOM to CSS transforms, and their performance pros and cons.
http://developers.facebook.com/blog/post/454
http://developers.facebook.com/blog/archive
https://github.com/facebook/jsgamebench
If you are just drawing simple geometry objects you can also use divs. They can be circles, squares and lines in a few CSS lines, you can position them wherever you want and almost all browser support the styles (you may have some problems with mobile devices using Opera Mini or old Android Browser versions and, of course with IE7-) but there wouldn't be almost any performance hit.