I'm developing an application which involves a slides translating into view as the primary navigation mechanism. The first slide to come in involves several super-imposed PNGs at roughly 2000px squared with transparencies, and there's a notable framerate stutter as the images come into view.
Using Chrome Dev Tools' Timeline feature I've established that while most of the individual Paint tasks take under 5 milliseconds each, the significant outliers are those Paint events whose subtasks include decoding the PNGs, which take between 50 and 100 milliseconds one after the other, seemingly at the moment the images come into view.
Ideally I would like to decode the bitmaps ahead of time, but I can't think of a way of forcing this behaviour without actually rendering them in view. Any ideas?
If the bottleneck is decoding, then pre-render your images to a canvas, and then either draw those pre-rendered canvases to your view canvas or translate them in using CSS.
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
My site have a big css sprite image.
Site: http://www.protohaber.com/demo
Sprite Image: http://www.protohaber.com/demo/templates/v1/images/proto_sprite.png
My site is works slow (e.g. page scrolling slow, etc..) at browser in some computers (low cpu computers)
Maybe you should try to use PNG Gauntlet to optimize the image.
Another Solution could be to split the Sprite into two or even more.
I think the principal reason for this is because the image is too big (almost 1.5 Megabytes), So just imagine how much the cpu have to calculate to move the background from one side to another. I think you sprite has a lot of resources which doesn't belong to it (like some images (the girl, caution alert, etc). Also you are mixing a lot of color at the same sprite which make the images bigger because has more colors to render.
I think one option is break apart the sprite into separate one which will make the file smaller (the slow processors can handle, render and move better small images), remove the images like (the girl, caution alert, etc) and make them jpg file which will make the file also smaller.
the idea of sprites is reduce the request to the server but if this reduce the performance of you application is best idea to make a couple of more request and have a better performance for the final user.
The typical rule of thumb when it comes to using CSS sprites for images is that you should only do it for smaller images (like icons) and that actual image content should always be represented through <img> elements. My question is: why? Aren't the advantages of spriting worthwhile for content images as well?
One reason I have read is to enable the use of alt text, to be more syntactically correct and accessible to screen-readers. However, when that is a concern, couldn't you just as easily use a single tiny transparent image with all the syntactical sugar atop a sprite that presents the real visual content?
You could, but:
Content images don’t tend to be re-used as much as UI-type images like icons. Imagine a newspaper site: if every content image they used in every story was part of a sprite, that sprite would very quickly get huge, and would be downloaded even by users who only looked at one story.
Website content is generally expected to be maintained by people who don’t know CSS. It’s a bit unreasonable to expect content editors to edit a master sprite image file, re-save out to a JPG, and pop in some CSS just to put an image on a page.
If you sprite a lot of large image files, the sprite file will get really large. It might take an unacceptably long time to download when the user first visits the page, or it might use up too much bandwidth on users who only end up seeing one of the images within the sprite.
Obviously, those are generalisations — in a specific situation, it might make perfect sense to sprite larger/more content-y images.
On using an <img> tag with a tiny transparent image file for sprites, you can do that for any sprite images — it’s often useful for clipping and positioning the sprite image beyond what background-position allows.
One additional reason I can think of, is search-engines; if you have an image with a descriptive alt-tag or a figure element with a figcaption, search engines will be able to find, classify and show it.
Sprites are usually usefull for static contents (images that are common on many pages).
Content pictures often appears in only one page, so you can't add it to your sprite file.
If you want to have real-time sprite generation, making custom sprite file with all your pictures, I think the generation cost is far more expensive than the duplicated HTTP calls it saves.
Sprites are here to save HTTP requests, but you should not waste server-side computation time to make it, nor put expensive and unusefull pictures in your sprite file.
Sprites should be used for common icons across the whole website and not for page specific content. When you use sprites for big images you get a lot of white space that is wasted.
According to http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/ this is also a problem:
Another (but much less important) downside is that if a sprite-using
page is zoomed using the full-page zoom feature that’s present in many
browsers, the browser may need to do extra work to get the correct
behaviour at the edges of these images — basically, to avoid adjacent
images in the sprite from “leaking in.” This isn’t a problem for
small images, but can be a performance hit for bigger ones.
From the research I've continued to do on this, another potential issue is memory consumption. Despite the fact that sprites may be compressed enough to download quickly, the footprint they fill in the client machine's memory is after the browser has rendered them, meaning it can be quite large, even for sprites with fairly small file sizes.
I haven't seen a definitive answer on whether or not this memory footprint is any larger than what one would see when loading the same number of images without sprites. I will be testing that in the coming weeks for the project that prompted this question, so I will return and update this answer once I have a conclusion.
Sprites are used to reduce the amount of requests to a server. The impact of lots of small requests is slowing the server more than one bigger request. But if the image of sprites, I like to call it sprite-map, is too large, it will also slow down the performance. The other thing of importance is like you sad the possibility for each single picture to give some name, to manage and to index by search engine.
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.
How do you approach the use of image sprites in css?
Should I take all the images in my website and combine them to one image sprite? Is it really that beneficial?
How hard is it to maintain those images and change them later on?
Should I take all the images in my website and combine them to one image sprite?
Of course not. You're taking it too literal.
I find sprites are best used for groups of similar images. Examples include:
All states of a graphical button
States of icons
All permutations of a background (unless it needs to tile two ways)
Is it really that beneficial?
If you have a lot of them on a busy site, very. It saves a request for each image, saving the user time and your server a whole bunch of concurrent connections.
How hard is it to maintain those images and change them later on?
If you've used them logically, pretty simple. If you need to add another navigation item, you open up your nav sprite and expand it. For things like navigation it can actually be easier to maintain because you have like comparisons right next to you in the same document.
Edit, having seen one of the more extreme examples, I'll add that I would never go that far because:
It's 60k to download. Not huge but on slow connections, that's 60k that has to be downloaded before anything shows. If all your visual assets are tied up, it can make the load time seem longer.
Your CSS becomes a nonsensical mish-mash of background-position commands. If you do want to make changes you have to go back to the sprite and measure everything. Again and again and again.
God have mercy on your soul if you need to enlarge something in the top-left of the sprite. You'd probably just add a new sprite below the current ones.
And that might lead to bloat. Indeed, just loading all these images might be loading a whole lot of material that some users will never actually see. Loading unused data is probably worse than a connection overhead (considering how easily static content can be served by multiple cheap servers or a CDN)
The other examples are a lot more simple and worthwhile (IMO).
Sprites are a great way of cutting down load-time on graphics (sometimes), and always a way of cutting down requests to the server. Generally speaking, they may take some serious planning as you don't simply want to drop a bunch of images onto a canvas and export as a jpeg. I would suggest you study some sprites currently in use by larger companies like Amazon. Get an idea for how they layout their elements, and what types of images they even consider for use in sprites.
You'll also want to evaluate your site and be sure whether you can successfully implement them or not. If you weren't planning on using them to begin with, it may require a lot of back-tracking and updating to prepare for them.
Amazon Sprite
Ebay Sprite
Current.com Sprite (Whoa)
Google
Sprites work well when you’ve got an element with at least one fixed dimension (width or height), and you want it to have a different background image in different circumstances.
When I’ve tried it, I’ve found that sprite image files tend to be smaller than the total size of the individual images files they’re made from, so you can get bandwidth savings as well as the other two benefits:
fewer HTTP requests
no delay waiting for another image to download when an image state changes on hover
That does depend on the contents of the images though.
Personally, I wouldn’t put unrelated images together in one sprite image, as I think it makes maintenance too non-obvious. Also, as mentioned in To Sprite Or Not To Sprite, really big sprite images can use quite a bit of browser memory. (Whether this is actually a bad thing depends on the context.)
The idea is to avoid unnecessary HTTP requests. This is especially an issue if you have a lot of small icons (say, for a WYSIWYG editor like the one used on this site). If you have twenty 16x16 pixel icons, that won't amount to much bandwidth, but it will still mean twenty extra requests each time the page is loaded.
Other candidates for sprites are button states and anything that's purely decorative but part of the layout.
If you use roll-over background image changes, you'll also find that you'll either have to preload the roll-over state image (either with JS or with silly hardcoding) or you'll encounter some latency as the browser requests the previously unused image. Sprites can alleviate that.
Things you probably shouldn't be making sprites of are pictures that are NOT just graphical elements (e.g. graphs, illustrations, avatars, ads) or that will change a lot (e.g. avatars or ads).
It's not impossible to change sprites, but depending on how much thought you put into the arrangement of the sprite sheet, it may be very hard to do. There's nothing forcing you to make the sprite sheet ultra-condensed, but it's obviously better for the file size if there's not much unnecessary whitespace in it (see Google).
Note that the extra requests may not be a problem for you if you have a relatively low traffic site (which almost everybody has, unless you're Google or Amazon). Sprites may still improve performance for mobile devices, though, as it means less chances for errors and thus lower latency.