Recently I have heard that you can create forms like a rectangle for example with css3, but i wonder why would I ever do that, doesnt it only cost more time in comparison to images?
I can only imagine that it would be better for pageload speed.
Okay now to be clear of few things... Images and CSS are two different things.
Speaking about form, if you want a rectangle, then you can just have some tags like div tag, and style them using CSS.
CSS is way faster than loading few images. If u wanna use images for designing purpose such as creating a rectangle, then its better to use CSS to get the effect.
Gone are those days when people used to use image to style up the website. CSS are ruling now. Unless its an album thing, or slider, or background image, or profile image, etc don't use image for designing purpose.
Also, with CSS along with few tags, you can create few geometrical objects like arrows, circle, rectangle, squares, etc.
Speaking about time, being a developer, you have to look at the TIME COST from clients prospective always, than developers prospective. Things can be get done in a jiffy, and unorganized manner, but comes in huge cost.
Related
I asked this question recently: How can I create a CSS border on a diagonal element
Question: Is it more memory intensive or cpu intensive to use image or complex css for a navigation menu?
Question: Cross browser/screen size aside, is the an advantage to one over the other for reasons other than what is mentioned above?
Thank you!
Ultimately, the device needs to display an array of pixels. If you send an image file of those pixels, they are ready for display. If you send complex css for creating those pixels, it will likely take fewer bytes across the network but the processor will need to render the pixel array before it can be displayed.
Whether you should use css or an image depends on a variety of considerations. Here are a few:
Is the thing you need to display always exactly the same size? Then an image file has the advantage of already being rendered. If not, css will give the capability to size efficiently.
Will the user always have a good network connection? If so, there won't be as much of a performance penalty for sending a pre-rendered image and possibly a bunch of media query css to decide which image to load.
Is the thing you are trying to render very large on screen? If so, css might have an advantage over loading a large image file.
Is the css extremely complex, taking lots of code to describe? Then an image file has the cpu advantage of being pre-processed.
Are there animation states or other animation associated with the display item? Then css has the advantage of not having to load multiple potentially large image files. But, if the states have very complex animation taking lots of code and therefore cpu, then the previous guideline will apply.
Second question: If there are cross-browser difficulties with your css, a pre-rendered image will eliminate those. But, if you are building a responsive display object that has very many different display sizes, css will have the advantage of scalability. That said, a basic concept in responsive design would be to provide a few different size versions of an image.
In general, image files cost bandwidth and css/vectors cost cpu.
My project's creative designer and I have had some amicable disagreements as far as whether it is better to use slices of his comp or rely on the browser's rendering engine to create certain aspects of the user experience.
One specific example is with a horizontal "bar" that runs the entire width of the widget. He created a really snazzy gradient that involves several stops of different colors and opacities, and he feels that the small size of the image is preferable or at least comparable to the added lines of CSS code needed to generate the gradient natively.
We're already using CSS sprite technique to reduce the number of return trips from the server so that's not an issue for us. Right now it's simply the pro's and con's of using sliced up imagery versus rendering with CSS and HTML.
Is there a definitive rule as to how large an image needs to be to be the "worse" option of the two?
UPDATE: Since a few people have mentioned the complexity of the gradient as a factor I'm going to present it here:
-webkit-gradient(linear, left top, left bottom, color-stop(50%, rgb(0,0,0)), to(rgba(0,0,0,0.9)));
Very complex! ;-)
Measure it! Not the answer you like I think, but it really depends how complex the CSS will be and therefore how long it takes to be rendered.
In most cases it'll be the render time (CSS version) vs. request overhead and transmission time (image version). You will most probably see the big numbers here. Since you're already using image sprites you're reducing the request overhead to a minimum.
Browser compatibility should also be something you should be aware of. Here images will often win over CSS when it comes to gradients and something like that.
Some very complex CSS3-site to demonstrate what I mean: http://lea.verou.me/css3patterns/
This is a VERY nice case study, but incredible slow. It lags when loading. It lags even more when scrolling. And I am sure it is much slower than a solution using an image sprite for all of that.
Don't treat me wrong! I love CSS, but images are fine too. Sometimes even finer.
Summary
Measure it! When you do not have the time to measure, then estimate how complex the css would be. When it tends to get complex, then use images. When you've compatibility issues, then use images.
In general, if it can be done with CSS, definitely skip the image. If for no other reason it's easier to maintain.
HOWEVER, a complex gradient is likely where I'd give in and throw in an image. Having recently implemented some CSS gradients, it is a bit of a mess right now.
Ultimately, Fabian Barney has the correct answer. If it's an issue of performance, you need to measure things. In the grand scheme of things, this is likely low on the performance issues to dwell on.
i think CSS is more reusable. Imagine you have to repeat the same image over and over again in the same web document. Lots of HTTP requests there. But that's my opinion, please correct me if I'm wrong I think CSS is way more expressive and flexibly stylish.
However, there are things you have to watch out for. Stuff like browser specific prefixing kill pages with too much CSS.
In a design that I'm working on, there is a recurring image background shape that appears several times in different sizes throughout the site. For example, one page uses it as a huge background images, where the top and bottom part of this image is cut off by the browser edges.
It's not an easy pattern to create with canvas, but as far as I know it's possible. Here's what it looks like.
Am I better off making several images of this same pattern or is this background image easy to recreate through canvas? If it is appropriate for canvas, how do I go about recreating it in the various sizes? I wish I knew how to begin something like this using canvas but it's above my skillset.
I've converted your shape to an SVG shape here: https://gist.github.com/1321653 — use it as you'd like.
According to caniuse.com, SVG is supported on all common browsers except for IE8 and earlier.
For IE8 and earlier you might be able to combine canvg, a SVG-to-canvas library, with explorercanvas, a canvas emulator for IE8 and earlier. Or you could display a rectangle with a background color — IE users might not miss the splat.
Edit: You could also get creative with CSS3 background gradients, ala http://www.ecsspert.com/ (famous logos created with only CSS), but compatibility is low across browsers.
Suppose we're making a strategy game (think Civilization) in a web browser. The game has a visible map portion - say 30x30 squares. Each square is 30x30px and has several overlaid images - the terrain, resources, units, roads, etc. The classical way of drawing this would be with a huge <table> where each cell would contain absolutely positioned images. It would probably be rendered in Javascript to reduce traffic. But it's still several thousand images and a huge table.
Can the browser take it? Will the performance not drop below any acceptable limits? Alternatively I could keep a pre-rendered map image with as many overlays as possible, but that would be more work, I think.
You should really look into using the canvas element which does not require the browser to store and compute the whole layout and other DOM stuff.
That being said, a modern browser on a high-performance workstation can display hundreds of images at the same time as demonstrated with the FishIETank. However, many devices - ranging from smart phones to old PCs - can not. Oh, and using a table is probably slower than a div with position:relative; or absolute and absolutely images therein.
Look at online games like grepolis, they already do some sort of a grid like game, and modern browsers can take this easily.
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.