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.
Related
I have already read
What is the difference between SVG and HTML5 Canvas?
&&
https://en.wikipedia.org/wiki/Canvas_element#Canvas_versus_Scalable_Vector_Graphics_.28SVG.29
So i am aware of the basic differences, but i was wondering if anyone had encountered any practical difference between the two within the context of ggvis and shiny apart from SVG inability to deal with NA's in the data
The short answer:
SVG would be easier for you, since selection and moving it around is already built in. SVG objects are DOM objects, so they have "click" handlers, etc.
DIVs are okay but clunky and have awful performance loading at large numbers.
Canvas has the best performance hands-down, but you have to implement all concepts of managed state (object selection, etc) yourself, or use a library.
The long answer:
HTML5 Canvas is simply a drawing surface for a bit-map. You set up to draw (Say with a color and line thickness), draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is that you've just drawn, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.
SVG on the other hand must maintain references to each object that it renders. Every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default, but it slows down significantly when there are a large number of objects
Those SVG DOM references mean that some of the footwork of dealing with the things you draw is done for you. And SVG is faster when rendering really large objects, but slower when rendering many objects.
A game would probably be faster in Canvas. A huge map program would probably be faster in SVG. If you do want to use Canvas, I have some tutorials on getting movable objects up and running here.
Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.
I've run a bunch of numbers on HTML DIV-made drawing versus Canvas-made drawing. I could make a huge post about the benefits of each, but I will give some of the relevant results of my tests to consider for your specific application:
I made Canvas and HTML DIV test pages, both had movable "nodes." Canvas nodes were objects I created and kept track of in Javascript. HTML nodes were movable Divs.
I added 100,000 nodes to each of my two tests. They performed quite differently:
The HTML test tab took forever to load (timed at slightly under 5 minutes, chrome asked to kill the page the first time). Chrome's task manager says that tab is taking up 168MB. It takes up 12-13% CPU time when I am looking at it, 0% when I am not looking.
The Canvas tab loaded in one second and takes up 30MB. It also takes up 13% of CPU time all of the time, regardless of whether or not one is looking at it. (2013 edit: They've mostly fixed that)
Dragging on the HTML page is smoother, which is expected by the design, since the current setup is to redraw EVERYTHING every 30 milliseconds in the Canvas test. There are plenty of optimizations to be had for Canvas for this. (canvas invalidation being the easiest, also clipping regions, selective redrawing, etc.. just depends on how much you feel like implementing)
There is no doubt you could get Canvas to be faster at object manipulation as the divs in that simple test, and of course far faster in the load time. Drawing/loading is faster in Canvas and has far more room for optimizations, too (ie, excluding things that are off-screen is very easy).
Conclusion:
SVG is probably better for applications and apps with few items (less than 1000? Depends really)
Canvas is better for thousands of objects and careful manipulation, but a lot more code (or a library) is needed to get it off the ground.
HTML Divs are clunky and do not scale, making a circle is only possible with rounded corners, making complex shapes is possible but involves hundreds of tiny tiny pixel-wide divs. Madness ensues.
I have past content from the following link.
Please see this link for more details
HTML5 Canvas vs. SVG vs. div
Our application at work uses the ExtJS (Sencha) framework for the UI. The problem I have with the framework is the amount of HTML that is output by the framework.
I have noticed that the areas of the system that are reported as being slow by users have a ton of CSS calculation calls. I measured this in Google's Speedtracer and some pages take 8seconds to load. 80% of the time is dedicated purely to CSS calculations. Before trying to alter the way the framework works, is there anyway to delay CSS calculation of a page, or are these calculations done when the objects are rendered?
I have been searching for ways to do this, and maybe my "google-fu" is terrible, but I haven't found anything concrete on how to achieve something like this.
EDIT: After speaking a colleague, he pointed me in the direction of calling .suspendEvents() on the grid before loading any data and .resumeEvents() afterwards, this alone has saved 300ms of loading time :O This is reducing the number .getStyle calls detected by Firebug. I am yet to test this difference with Google SpeedTracer
It's hard to say what's causing your performance problem without knowing exactly what your app is doing. CSS will have some impact but not much, it's more likely that some JavaScript in your app is causing excessive reflows while the page is rendering.
Summary of stubornella's article (the second link)
Reflow is the process by which elements in a web page get laid out according to the style rules. A reflow is computationally expensive but it is usually possible to draw a static HTML page in a single reflow as long as the rendering of any later elements doesn't effect elements that have already been drawn. Things which are likely to lead to multiple reflows and some work arounds:
Dynamically adding CSS classes to elements - change classes as low in the dom tree as possible to limit the impact
Adding multiple DOM elements - create an invisible structure and add it in a single operation instead
Adding multiple inline styles to visible elements - better to create a class with all the styles, then apply the class
Applying animations to relatively positioned elements - better to animate position: fixed or position: absolute elements as they won't impact anything else
Fine grained animations - moving an element 3px at a time may be more smooth than moving it 1px at a time because you avoid two reflows
Tables are one of the few cases where the rendering of an element later in the DOM can change how an earlier element should be rendered - if you must use tables, use table-layout: fixed
We have also been struggling with the overhead of using extJS - although the framework is very comprehensive, the performance hit (especially with IE6) has been a big limitation. Here are some of the steps we took to optimize the framework:
Streamline the library to only include the packages that are used on your site. This means customizing the jsb2 file and rolling your own extJS deployment.
In our performance testing we've identified the CSS to be the biggest offender. A benefit of using a custom build of extJS is the reduction of unused CSS selectors. To further optimize the CSS, we used Google's Page Speed to identify the CSS selectors that are inefficient to refactor/remove them. Pay particular attention to:
Pseudo :hover selector
Universal * key with descendant selectors
The resulting ext "lite" should yield significant performance gains, particularly in IE6. Although the Secha team are making continuous performance improvements with every release, the overhead of loading the entire framework is too expensive to ignore.
Hope this helps...
Smartoptimizer is really awesome, have you tried any of those types of gzip code compression type tools?
https://github.com/farhadi/SmartOptimizer
I'm working on a web app that currently has a table-based layout. Ideally I'd like to go to pure css, or failing that, a hybrid tables-and-css layout* .
I've banged my head against the wall trying to understand css layouts and positioning. The main problem I'm encountering is that, depending on the state of the app, I have different things appearing in a 'section' of the layout -- what might be contained in a div or table. For instance, I might have some text and links, and then after user interaction, there might be a form, a table, some images, different text, etc. Anytime I find a css solution, it is for a fixed-element layout, or works in a specific case, etc. They're not robust solutions, in other words.
From this In Search of the One True Layout, the author about "Vertical placement of elements across grids/columns": "Designers face the choice of relying on elements being a particular height, resorting to tables or simply not bothering." Is this true? In my app, I can't rely on elements being a particular height.
Do I fall back on tables when I have elements of various hieghts ( which is quite a bit of the site, actually). I noticed that quite a bit of sites done by well-respected people and organizations use tables for layout in certain places, and not just for tabular data! This site included.
The chances are that there are CSS techniques to achieve what you want, but they may not be obvious if using CSS for complex layouts is new to you.
In your case, to 'get it done', I would recommend a hybrid type layout, and not feel bad about using a table to layout the pieces of the application that require those particular behaviours.
If it is particularly complex and difficult than a table might be the best and simplest approach even for the CSS expert.
Dynamic heights are only a problem if you need to implement a special effect of soem sort or a background image and oftent there are ways around that. It really depends on the Visual Design and what needs to be done to make each "block" flexible to use. Sometimes things arent possible but most of the time they are - they jsut tend to add complexity to the markup. But even that added complexity is easier for me to understand than nested tables :-)
My advice if you want to get things done and spend a ridiculous amount of time on css layout, browser compatibility, CSS reset, fonts:
write simple, valid, semantic HTML
use a simple CSS framework (like blueprint). You will rely on a simple grid system for positioning and layout.
add CSS classes to your HTML
add your custom CSS for colors, backgrounds...
Please reconsider using a table layout 'to get it done'; you will be disappointed, especially if you want to add some JS magic later.
I use CSS layouts for my web apps. But, my apps don't have wildly varying information, so I can set the content area and not have to worry about the layout looking "off" because a column is way out of balance with the rest of the content.
If you're having trouble with CSS layout and positioning, I'd suggest tables first, learn more about CSS/HTML positioning, and then convert your layout LATER. I'm sure that it's made for a frustrating experience learning CSS on a "real" project.
In the meantime, get some really good sources for CSS: books by Andy Budd, Simon Collison, Eric Meyer, et. al. Also, go to their blogs and dig into the archives. A really good book for CSS layout, positioning and general use is Beginning CSS Web Development by Simon Collison from APress. All the ins and outs with great working examples.
Having asked this question How to reach CSS zen?, I now understand that the issues I have are mostly related to positioning. I've found some articles telling that CSS is not always good enough as a layout system.
http://echochamber.me/viewtopic.php?f=11&t=40154
http://www.flownet.com/ron/css-rant.html
http://blog.workaround.org/2009/03/17/dont-abuse-css-for-page-layout/
Do you as CSS designers limit yourselves upfront to designs that CSS can handle? Should I avoid things that seems perfectly easy are in fact difficult to do with CSS?
Of course you limit yourself. As a designer, you should always think about the medium you're working with. If I were designing a magazine ad, I wouldn't be thinking about animations or video. There are certain rules you must adhere to, and it doesn't make sense to ignore that.
But of course, rules were always meant to be broken.
Why?
If you are "designing", why would you limit yourself based on a the limitation of one technology? When you design your site, you should always try to achieve the most usuable interface for the user.
If you do limit yourself, then you are just asking for the site to not be used, and then what's the point of creating it?
I don't limit myself upfront to any designs that CSS can handle (within reason of course), just figure out your design and there will be someway that you can get it looking right using CSS, but it might involve a lot of hair pulling, especially if IE6 is involved!
When implementing a web design (assuming I've got an image/drawing of what the site will look like) I always follow these steps:
I look at the design and determine what components it has. Examples are navigation areas, headers, content areas, and so on.
I implement (X)HTML that can represent the content areas without really taking the design into account (there are certain things such as content order that I use the design to determine.)
I start making the CSS and images needed for the site to look the same way it did in the original design document. Depending on the complexity of the design, I might come up short of elements to use for styling the page, and may end up adding elements that don't really make sense for the content. I try to avoid it as much as possible, though, and I try to create the elements in a way that isn't obtrusive to the content.
As you can see, I never limit the design to the capabilities of CSS. CSS comes last. Now, depending on the complexity of the design, it might not look exactly like it did in the original design document, but the goal is always to make it as identical as possible, while still maintaining clean HTML so that the design can easily be updated in the future.
Most layouts I find can be done with CSS. There are a very few exceptions (normally to do with verically centering text).
For me the main factor which limits my designs is a reluctance to use huge background images. If an effect can't be done by combining/repeating a few tiny bg images I tend to reject or tweak it. Eg a diagonal gradient on a box with curved corners which could be any height might fall into this category using CSS2.1
Almost every painter limits themselves to paint on canvas, almost every sculptor makes 3D shapes from stone or clay or metal...
But there's also the few who dream new dreams and create new things. Some flop, some shine.
Should you limit yourself based on what CSS can do with layouts? Not completely. I say dream big.
Once you've got your dream design, either figure out how to create it, find a technology other than CSS that can do it, or go start inventing!
You can do absolutely almost anything using CSS 2.1 as far as layout. Its a complete pain in the ass that has no reason to ever exist, but you can do rounded corners (using background images), gradient backgrounds (more background images) and all kinds of other bloated crap you don't need all together and still not completely destroy the semantics of your HTML.
Doing all that garbage and still attempting to be standards compliant reduces usability, because its the designers who need round corners and other frivolous crap and not the users. Usability tests have confirmed this. Sites that are bloated to accommodate presentation and usability at the cost of semantics and efficient fail in usability tests compared to their competition. I work for a website that gets several million visitors a day and I have seen the results of our usability tests.
CSS provides a very good way to create an overall design that easily can be changed by small changes in one CSS file, and instantly applies the design changes to all your pages. Of course there are things that are tricky to do with CSS, and in those cases you might want to do it in other ways, but even if your layout is mainly based on CSS, doesn't mean that you can't do some special parts using other technology! You can mix!
So you don't limit yourself when you go for CSS. You just make use of a powerful technology that can be used in perfect harmony along with others!
I was told that there is an increase in performance when using Canvas versus HBox or VBox when laying out out the position of children. As a result, a number of our components have been converted over to using Canvas. However, now there is code being added to calculate the x and y positioning of some of the child elements based off of the width and height of other children. Is it worth using a Canvas to increase performance if code needs to be added to determine the coordinates/positions of the children? Is there a better method or technique available that should be practiced other than just minimizing the number of ui components added and specifying positioning absolutely?
There are a number of middle-of-the-road techniques, one of which is to use rendering-type components, such as TileGrid or ItemRenderers, if your layout fits a certain formula. If you're using forms, try using the Form layout component instead of using a custom layout.
If you do need to use the layout engine in Flex, the way to optimize your usage is to remember that certain techniques are used by the framework in increasing performance load, loosely following the below list, the last being the most performance intensive:
absolute positioning (<Canvas>)
relative positioning (<VBox>)
constraint-based positioning (right=0)
advanced constraint-based positioning (<constraintColumns>)
Using relative positioning is usually not that performance intensive. If you are finding that it is, it could be that you're using too many nested containers. Look at your layout architecture and try to find out ways in which your objects may be "over-laid out", and simplify them. A good tool for this is FlexSpy, which lets you introspect object layout at runtime.
Another common performance bottleneck is that your application is attempting to do some number-crunching at the exact same time that your GUI is attempting to respond to user interaction. Although no green threading frameworks exist at the moment which enable you to run UI and logic in separate 'threads', you can use a good architectural framework such as Cairngorm or Mate (there are many) which uses Commands instead of straight up methods, so that functionality execution which may take up processing cycles waits until the UI has finished responding to the user.
A couple things you want to keep in mind while optimizing a Flex UI:
Avoiding excessive nesting of containers. Consider using a Canvas with absolute or constraint-based positioning over nesting lots of HBox / VBox elements. However this doesn't mean you should NEVER use VBox/HBox. You can mix and match, such as using a Canvas as the main container and positioning child Boxes inside them as needed, just try to avoid too much nesting.
Using the UIComponent model properly in custom components. In particular, using invalidateProperties(), invalidateSize() and invalidateDisplayList() so that their companion functions (commitProperties(), measure() and updateDisplayList()) are invoked at an optimal time for the Flash Player. Deepa gives a great talk about this here:
http://tv.adobe.com/#vi+f15384v1002
She explains how making heavy use of the invalidation scheme allows the Flash Player to execute your code at an ideal time, i.e. not in the middle of a screen update. These principles are used by all Flex components and can/should be leveraged regardless of the framework being used.
To make sure I understand:
You heard that Canvas can position children faster than [VH]Box
Canvas only does absolute positioning
Some (many?) of your components have an absolute position, so you switched to using Canvas
But some of your components have a relative position, so you need to write code to position them
Is that correct?
Anyway, assuming I'm correct (which may not be the case), the first thing you want to do is pick the functioning interface which requires the fewest lines of code, then decide if it's "good enough". You want the one with the fewest lines of code because studies have shown that there is a correlation between lines of code and number of bugs (and you don't want bugs). You want to see if it's "good enough" because, if it IS "good enough", you don't need to do anything (if you do try and make it faster, you're committing Premature Optimization).
But that's probably not what you wanted to hear :)
So I'll also suggest that, if you want to stick with Canvas-based layout, you try sticking all the relatively positioned content inside [VH]Boxes, which are then absolutely positioned inside the Canvas. There's a good chance the code Adobe has written is faster than code, so you should try to take advantage of it.
But the only way to know for sure is to try it and profile it.