I am planing to setup all of controls ( more than 100 visible ) on a Flex application to alpha below 1, which will make them a bit transparent, but i am wondering if this will affect the performance of the application. So :
I would like to know if alpha actually affecting performance on Flex applications ?
To add to #Constantiner's answer, every filter and effect (including alpha) will affect performance. This is the case in any framework you work with... not just Flex. If you think about it, it makes sense...
You see, without any effects or filters, what gets displayed is straight forward... it is just a pixel. If the pixel is in front of every other pixel on the Z axis, it gets displayed. If not, it doesn't get rendered. No math. Very easy for the computer to manage.
In your case, you are changing the alpha. Now, for every pixel in front with an alpha value less than 1, you ALSO have to render to content behind it. Not only do you need to render the content behind it, you need to blend the pixels in order to get the transparent effect.
Of course, the framework and GPU take care of this work for you... but it comes at a cost. I am not suggesting that you don't use alphas. Just know that every time you add an effect or filter (drop shadows, glows, alpha blends, blurs, etc), the system has to do a lot more math for you. Your frame rate is directly affected by this... but it also produces a much better experience for your user.
Use that knowledge to make an educated decision. Does the effect/filter add value? Does the alpha move around a lot like in a scrolling list box (causing re-rendering to happen more often)? Will this extra overhead be OK?
EDIT:
Take a look at this presentation from 360Flex about optimizing Flex performance. I think it is very useful: http://zaa.tv/2011/06/360flex-denver-2011-flex-performance-tips-and-tricks/
Yes, it potentially affects performance. So use it wisely.
I mean if you're using controls with constant background there is no problems with it. But if you have a lot of objects which moves or added/removed to stage often you can have some performance issues.
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
Use of gradient images is very common among developers for styling a page. Gradient images are used in many places from styling the navigation bar to styling the background. Technique like repeating a small image in either direction is also common.
One more way to style and give this effect is by using multiple div's one below another with different color, the latter being a little lighter than the former. In the most simple scenario doing so would include only a small script. So, no problem of writing a lot of markup, just some simple code.
The only concern that remains is speed and performance.
Speed
The script, more precisely the function would be much shorter in size than a image. So, in matters of speed the latter method seems more good.
Performance
Today's browsers are very powerful, so the difference between displaying an image and executing a function is negligible.
Css management
Obviously, problems like positioning would be another concern but we do struggle with such problems in every day life. The problem is no greater than overlapping two div's and setting their z-index. The whole gradient div's can lie inside one parent div.
So having addressed the issues of performance and speed isn't using Gradient div's a much better approach than using images?
It's an alternate approach, yes. But not a good one. You get zero points for:
Maintainability
Scalability
SEO
Separation of presentation from content
Furthermore, to say that we needn't worry about performance since today's browsers are more powerful is a gross assumption.
Actually, I think the second option you describe (creating multiple divs with atering colour) is downright terrible.
You're altering markup for the sake of styling. That's a no-go.
It's a common thing among users to disable JavaScript. What happens then?
As you said yourself, positioning mayhem.
When it comes to performance, I would be more cautious than to state it's no longer an issue. Especially with the dawn of mobile browsers in mind.
Such styling would be harder to understand and maintain. Particularly when your team changes someday.
Also, there are two other ways to implement gradients.
CSS gradients - limited to simple variants and requiring a lot of CSS to provide decent cross-browser capabilities. You can try this generator get a taste of these: http://www.colorzilla.com/gradient-editor/
SVG backgrounds. These allow you to create just any gradient you wish. You can use an svg file in your CSS just like any other image. However, some browsers don't support this feature. Here's a table showing when it's an option
Using images is the most reliable option, while combining SVG with normal images (for these browsers that don't support SVG) seems the most flexible approach.
I'm working with a large flex applications and I have noticed that one of our largest components (with lots of child canvases) takes about 6 seconds between the initialize and creationComplete events. I've been doing some reading and have found that having lots of nested canvases can cause slowdowns, but i'm not sure if this is where the slowdowns would be? Anyone have any suggestions on speeding this up, or even diagnosing exactly where the slowdowns are coming from?
It's been my experience that nested containers with dynamic sizing are the most common cause of these types of lags. Some things to try:
Set explicit sizes/positions for your containers/components whenever possible. This reduces the incredible amount of measuring that goes on within the framework during the creation process.
Reduce the number of nested containers. Sounds obvious, but it's amazing how much you can cut away when you start looking critically at how your UI is set up. Specifically, are there HBox and VBox containers you can get rid of by simply setting explicit positions/sizes for the child components? Do you really need to use a Form container?
Switch your containers to the much lighter weight Spark Groups instead of using the heavier weight Canvas where possible.
Hope that helps. If not, post some code so we can dig in to your particular issue.
The biggest thing to consider is to use VBox's and/or HBox's in place of some dynamically generated x's and y's. VBox and HBox are much more efficient. Look into it!
Adding many display objects to the display list all at once can take a long time, especially if we're talking about Flex containers that have layout and scrolling logic in the mix. Since you say you're using many Canvas containers, that could certainly be the issue you're running into.
I know that a lot of developers abuse the creationPolicy property. Normally, it is set to "auto" which allows Flex to defer instantiation of a container's children until a very short time "later". Often, before the next frame, so you don't even see the difference. Do you happen to set creationPolicy to "all" anywhere in that hierarchy? This could be forcing the Canvases and their children to be created immediately.
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.