Trying to achieve something like this
http://attasi.com/labs/ipad/ which uses CSS transforms.
but using the Canvas object for greater compatibility.
Does anyone know if this is possible?
Take a look at three.js, it can render 3D using mainly WebGL, but it supports a subset of stuff with <canvas>, SVG and even the plain DOM - check this demo that uses the DOM renderer.
Here are demos using canvas. Some guy made this which shows it can do textured, animated game-like 3D with canvas.
Also, you may want to check out a particle engine and a tweening engine to go with that, plus stats like FPS.
Related
Famo.us claims that it "talks directly to the GPU" to compute themselfs the css transforms. I assume they are talking about the 4x4 transform matrix.
When they say the "talk to the GPU" it means they are doing their maths in WebGL?
When they show 3D elements are they using WebGL in a canvas element?
Is their technology real THAT special or their claims are the result of an excellent marketing campaign?
Disclaimer: I do not work for Famo.us, I just share their vision in way software should be built.
The answer to all three questions is no. When they say talks to the GPU, they are not referring to the matrix calculations, they are referring to the matrix3d property of CSS that is GPU accelerated by the browser. By throwing out the box model of normal HTML and CSS, we can create a new model that follows the likes of traditional graphics development, which is based on a Cartesian coordinate system and all elements are absolutely positioned with 3d transforms.
There is no WebGL and no write to canvas. Every one of the (surface) elements on screen is just a div that is transformed. Every bit of text will still be highlightable and every button will still be clickable. It's all live. The rendering starts at the Context, which in most cases is the top level of the render tree. Nodes for other subviews are added as children. On each render cycle the context's render function is called, which in return looks down the tree and calls the render function of each subview recursively. Since the render engine is tightly integrated with requestAnimationFrame, all calculations can be determined then rendered at the time of screen refresh.
The technology can be considered special, because it throws away so many traditional paradigms in favor of a more modern approach to building web applications. That being said, it's really only Javascript. HTML was not built for web applications. HTML and CSS were built for static content pages and work as a crutch in trying to achieve applications similar to the ones we love and adore on mobile. Famo.us makes it possible to build applications with only JS, or a compile-to-JS language like CoffeeScript. You define Surfaces which correspond to divs on screen, and you apply properties for HTML attributes and CSS. You still have the option to apply CSS classes or inject HTML into surfaces.
In the end the choice is up to you. If you do not see the value, or are comfortable with the way you build web applications, then stick with it. Over the next few months you will see many more demos popping up as real users like myself create them. I can tell you already, it's amazingly promising.
Cheers
I want to add a slightly updated answer:
(I, too, don't work for Famo.us, but I did spend three weeks there working on projects)
While #johntraver has summed up pretty nicely what Famo.us does at the moment, it is important to understand that famo.us WILL support canvas and webGL.
Going deeper into the philosophy of famo.us, it throws away all the tools that HTML and CSS provide for layout and animation. ALL surfaces in famo.us are absolutely positioned at top:0, left:0 and EVERYTHING else is done purely with transforms, that are calculated by famous.
Animations are also done in javascript and don't use CSS transitions or Animations.
The more you think about it, Famo.us has almost no dependency on HTML or CSS, and that is exactly the plan. Famo.us treats HTML as just one of many possible renderers.
They are now working on adding WebGL rendering to famo.us. Essentially, what this will enable is a common API for layout and animation that will be able to render to WebGL AND HTML for the best of both worlds.
So, calculations will still be done in Javascript entirely, but the output may either be surfaces with transforms OR WebGL.
Hope that helps.
I want to draw a tree on the screen where edges and nodes both have labels, user can zoom on the tree and users can change the locations of objects. In java there is a good tool named "JHotDraw". Is there anything like that for .net or / asp.net?
You will need to use javascript to render on a browser.
Take a look at the library TheJit.
ASP.NET is a server-side technology. You could use System.Drawing namespace (GDI+) to create static graphics from the server side, but... have you considered using SVG or Canvas?
The first - SVG - is a client-side markup to render real-time vectorial graphics in a regular HTML page.
Canvas is a client-side, 2D pixel-based rendering also for regular HTML pages.
Depending on your needs, you may choose SVG or Canvas.
Mozilla Developer Network (MDN) has good resources for learning more about both:
SVG on MDN.
Canvas on MDN.
CSS3 allows developers to implement simple graphics without using images.
For example this envelope gradient background:
Is there a way to generate a square-based ornament via css3. An example is slavik ornament like this:
I am not asking for an example, just if it can be done by setting a square color and position. Perhaps it is too complicated of an ornament and needs to be provided at least as svg image.
Look at those examples
http://lea.verou.me/css3patterns/
there are some complex ones there.
But be aware that this technique tends to be heavy on the cpu especially in Firefox.
You may also try to generate those using javascript in canvas that is positioned offscreen, capture its content as image and use that image for background. Here is an example how you can implement this
http://www.html5canvastutorials.com/advanced/html5-canvas-save-drawing-as-an-image/
Sencha Animator is using CSS3 animations exclusively.
RaphaelJS is using SVG animations.
I wonder what are the similarities and differences between SVG and CSS3 animations?
Could one be used instead of the other or are they for difference tasks?
Ok. I have a whole presentation with an introduction to CSS Animations and A little on SVG.
But here are the oversimplified essentials:
The CSS Animation spec (per se) is just equipping you to declare "key frames" or multi-step transitions between Styles.
"Styles" in CSS3 includes "Transform" which specifies the scale, rotation, skew and position offset of a page element.
It's possible to "Transition" between styles, and specify the time and pace of that transition, to the extent, even, of declaring a cubic bezier timing function.
Combining Animations, transitions and transforms gives you an easy, declarative way of moving and transforming ANY page element (an img, a div, a video etc.) in a very rich way, that also progressively degrades nicely in older browsers (as long as you're sane about things).
BUT every element is essentially treated as an undifferentiated 2d rectangle for the purposes of animation, so its really all about animating sprites. At Sencha, as you've noted, we've even built a whole CSS Animation tool around this. And you should take a look at some of the demos there because it shows that you can really do a lot with the small set of primitives that CSS gives you. - Product Discontinued.
SVG Animation can be performed using the built in SVG animation capabilities (animate, animateelement etc.), SMIL (a declarative animation description similarish to CSS Animations) or JavaScript), has a richer set of capabilities than CSS Animation, but only because you're creating SVG Objects and changing their properties. You can't use SVG "animation" to, for example, animate an existing piece of HTML.
But it's also much richer. The biggest gain in SVG is that you're declaring drawing paths and fills with great flexibility (lines, arcs, quadratic arcs, cubic bezier arcs etc. etc.) and you can change the value of these properties over time using transforms and key splines (similar to timing functions in CSS Transitions)) This allows you to perform "rigging" animation rather than sprite animation. (I'm not an animator, I'm just using the terms I think are appropriate). So you can actually draw things like this cat walking across the screen, using line animations impossible to perform with CSS Animation (or impossible to perform for people of reasonable sanity - if insane people want to declare large numbers of zero height divs with border radii and use transforms to simulate arcs, then it's a free country.)
On the other hand, SVG is a PITA if you're writing it unassisted (verbose XML style with XHTML dtd). I'd highly recommend Raphael if you're a JavaScripter - Raphael has the benefit of degrading to VML vector graphics in older IE. SMIL (declarative animation for SVG) is a nice idea but it's not properly supported in many places. Also many browsers don't properly support SVG and those that do, often support it incompletely, particularly when you try to animate properties.
Update: there are many more updated animation libraries nowadays including snap.svg, greensock and others.
And there's no SVG support in Android 2.x, so if you want web animations that work on phones you're stuck with CSS Animations.
Having taught myself the basics of SVG animation in order to develop the intro presentation linked at the top, I can give a hearty thumbs down to hand-writing SVG. It's hard to remember, it's non-intuitive and because its XML, it tends to either work completely or fail completely, making it frustrating to debug.
They are completely different.
SVG is a vector image format. It is used to create infinite-resolution images using paths and basic shapes:
CSS3 animations, however, are just web browsers smoothly interpolating CSS properties like color, padding, font-size, etc. As you can see, the scope of CSS3's animations is very limited.
I'm trying to make a wheel, which will be sliced into different coloured sections (kinda like a pie chart) but they may have extra elements on top of them, e.g., a stitched border across the borders at the side and an icon at the edge of each, etc.
So my question is do I just use css3 (examples: http://www.css3shapes.com/)
and then use something like http://css3pie.com/ for Internet explorer 6-9?
Or am I just better off doing it in Photoshop and slapping it on a div as a background image? And use absolute positioning for extra elements?
Which is the best practice?
I would (and do) use PHP's GD extension to create a pie chart based on input data, save the image generated by that, and optionally generate an imagemap so parts of the chart can be highlighted, have tooltips, etc.
I really wouldn't use CSS for drawing shapes. It's hacky at best, and can get really messy. Quite a few of the examples in the cssshapes site you linked to don't even work in Firefox 3.6 - which is still quite heavily used - let alone other older browsers, and in IE you'd really struggle; css3pie won't give you the kind of fine-grained control you'd need for a pie chart.
If you want to draw stuff on the browser using on the client side, there are a number of ways to do so without resorting to hacks like CSS shapes.
Both SVG and Canvas are relatively new technologies for placing and manipulating graphics on the browser. SVG draws vector graphics and Canvas is for pixel-based graphics.
Both of them are supported on a wide variety of browsers. The obvious exception being IE8 and earlier. However, IE does support an alternative graphics format called VML, and there are javascript tools for IE which allow it to convert both SVG and Canvas into VML, so you can use either of them and they will work in IE using these tools, which makes both SVG and Canvas effectively cross-browser compatible.
But if you're drawing pie charts, or similar sorts of things, my personal recommendation would be to use the Raphael library. This is a javascript library which works in all browsers, and can be used to draw and animate pretty much anything, including graphs and charts (it even has a separate graphing add-on library. See the demos on those two sites to see what it's capable of; I think you'll be impressed. (I certainly was)
Hope that helps.