I can't find an answer to this question, when the browser takes an SVG from the cache does it re-compute the xml or not, does it store the 'IMAGE' that it has already created? (How?)
I would've have thought not, but then I've noticed how fast repeated svgs load.
I've also noticed slowness on a page logo (in mobile browsers) which make me think THEY re-compute the SVG, so i've moved to PNG's (which are obviously cached) for mobile to save a lot of computational work for the low end phones.
So maybe, does the answer depend on the browser / browser type / browser settings?
*my svg's are compressed svgz's by the way
Sometimes it does and sometimes it doesn't. Most browsers go to some effort not to rerender things unless they have to. There is a buffered-rendering property in SVG 1.2 Tiny that may help if you're using Opera, other browsers try to do things automatically without requiring such hints though.
Browsers generally don't cache SVG content as a simple bitmap though. They do cache things like the absolute position and size of shapes and text with transforms applied, the css tree structure, gradients etc and then use this information they can redraw the content much more quickly than having to work it out each repaint. Such information allows browsers to copy with javascript and SMIL animation of parts of the SVG content as well as user scrolling.
Related
All in the title.
I want to do whatever will be fastest.... I would think that 5 CSS generated circles would load faster than having to load an external image, whether its a sprite or not... but I'm looking for somebody who's more educated to offer an opinion!
The circles (to scale, presently generated with CSS):
http://puu.sh/3VZHO.png
First to answer your question as to which is faster... The CSS solution is quicker. But why?
The first reason CSS is faster is because of HTTP Requests.
Every time you have, let's call it an object, that object has to be loaded from the server. To do this the browser must send an HTTP request to the server for said file, the server has to check if you have permissions to access said file, if you do, it retrieves it's location, and sends it back to the browser. This happens multiple times and takes hundredths of a second to perform. Seems pretty quick, but the more of these you have to perform the slower your site will become.
CSS is fastest because the CSS for those 5 circles is contained inside one file style.css
The multi-circle image sprite is slower than CSS because now, not only does the server have to send you style sheet for the rest of the site, it also has to send the your image sprite. Think of this as ordering a quantity of 2 of the exact same thing from amazon from the same seller. Amazon will package both items into one big box because its cheaper. Where ever possible you want to piggy back things like this because it's "cheaper" on load times.
As a further explanation, if you were to load the 5 circles all as separate graphics, 5 individual jpgs/pngs/gifs etc. This would take EVEN longer because it would have to perform 6 HTTP Request as opposed to 2, or even 1 (the css solution).
The second reason CSS is faster is because of shear file-size.
Let's assume the CSS for your circles has 8 lines of CSS code for each circle, that's 40 total lines. That represents just bytes of information compared a couple kilo bytes. To put that better into perspective you are talking 100-400 bytes compared to 4,000-8,000 bytes.
The clear winner? CSS
Other Considerations
That said... There are other factors which should weight in on your decision. Not all browsers support border-radius. See this link for details on what does support border-radius: Can I Use
Since IE8 and below does not support border-radius anyone using IE8 or earlier will render your circles as boxes instead. You can help this along by using something like Modernizr to fill in some of those gaps. But now, even if you use a build of Modernizr that helps only border-radius, you've added 7+kb of data and an extra HTTP Request with this file, which sort of defeats your purpose. That is of course unless there are other things you can use Modernizr for other than border-radius, or if you have a lot more utilizing border-radius than just those 5 circles. Suddenly the extra data and HTTP request can be easily justified.
Ultimately your decision should be based on your target audience. What browser are they most likely to be using, if they are mostly using IE9+, Chrome, Firefox etc. Then go for it. If a significant number of your visitors are IE8 and below you should consider providing a fallback. For example using that image sprite for IE8 and below only.
It all depends also in your needs.
I think the border-radius is not rendered correctly in old IE versions, so...maybe the image sprite is the best solution. But I repeat it all depends. Maybe your clients are in a place where internet is slow (css is best) or maybe they won't update their IE and are stuck in IE6 or 7 (sprites).
You could use both, using one stylesheet for IE with sprites and one for css border-radius.
Check the paint times via the chrome dev tools.
Should give you a good idea.
B
Very large images will not render in Google Chrome (although the scrollbars will still behave as if the image is present). The same images will often render just fine in other browsers.
Here are two sample images. If you're using Google Chrome, you won't see the long red bar:
Short Blue
http://i.stack.imgur.com/ApGfg.png
Long Red
http://i.stack.imgur.com/J2eRf.png
As you can see, the browser thinks the longer image is there, but it simply doesn't render. The image format doesn't seem to matter either: I've tried both PNGs and JPEGs. I've also tested this on two different machines running different operating systems (Windows and OSX). This is obviously a bug, but can anyone think of a workaround that would force Chrome to render large images?
Not that anyone cares or is even looking at this post, but I did find an odd workaround. The problem seems to be with the way Chrome handles zooming. If you set the zoom property to 98.6% and lower or 102.6% and higher, the image will render (setting the zoom property to any value between 98.6% and 102.6% will cause the rendering to fail). Note that the zoom property is not officially defined in CSS, so some browsers may ignore it (which is a good thing in this case since this is a browser-specific hack). As long as you don't mind the image being resized slightly, I suppose this may be the best fix.
In short, the following code produces the desired result, as shown here:
<img style="zoom:98.6%" src="http://i.stack.imgur.com/J2eRf.png">
Update:
Actually, this is a good opportunity to kill two birds with one stone. As screens move to higher resolutions (e.g. the Apple Retina display), web developers will want to start serving up images that are twice as large and then scaling them down by 50%, as suggested here. So, instead of using the zoom property as suggested above, you could simply double the size of the image and render it at half the size:
<img style="width:50%;height:50%;" src="http://i.stack.imgur.com/J2eRf.png">
Not only will this solve your rendering problem in Chrome, but it will make the image look nice and crisp on the next generation of high-resolution displays.
Basically, I want to save a certain DOM element of my page as an image, and store this on a server (and also allow the user to save the image to a local disk). I reckon the only way of doing this currently is to render a canvas, which allows me to send the image data via AJAX and also make image elements in the DOM. I found a promising library for this, however my DOM element has
multiple transparent backgrounds
css 3d tranforms
And html2canvas simply fails there. Is there currently any way to neatly save an image representation of the current state of a DOM element, with all its CSS3 glory?
Browsers may never allow a DOM element to be truly rendered as it is to a canvas, because there are very serious security concerns around being able to do that.
Your best bet is html2canvas plus your own hacks. You may simply need to implement your own render code in a customised way. Multiple backgrounds should be doable with drawImage calls, and you may be able to work in css3 transforms when canvas 2D gets setTransform() (which I think is only in the next version of the spec).
In this stage of CSS3 development and crossbrowser support is this probably not possible without writing your own html2canvas extension.
You can try dig into Google Chrome bug reporter as they allow you to send current snapshot of web page. But I think it's some internal function which isn't available in JS api.
Also, I think this can be easily abused for spying on users, so don't expect any official support from browser development teams.
My website seems to take on this "squeegee" type load effect, where all of the graphics load from the top down with an ugly top to bottom wiping effect. Is there a way to make the actual way in which your website renders graphics prettier?
I'd be more interested in why your page is taking so long to load and/or render. If it takes several seconds to draw, even on a fast connection, you might want to look into why that is. Tools such as Fiddler, Firebug, IE Developer Tools, etc can help you look at what resources your page is downloading and how big each research is.
If you have massive resources on the page (such as BMP or PNG files that are several hundred K), see if you can convert them to other formats or resize them on the server to the size they render at.
If your HTML is massively complex, such as huge nested tables, you might want to look into simplifying that with more modern HTML and CSS styling.
If you do have huge, high-res bitmaps that need to be loaded, you might want to preload them with script and then render them dynamically when they finish loading.
i'm buildling a website and I want to create a translucid menu. I know that .gif image types enable transparency, but from my experience, not translucidy(anything between being transparent and opaque) - by default it seems to set the opacity to 100%, ie a solid image without any translucity/transparency.
I'm not sure if the issue is with the file type, or with how I'm exporting my menu. If it's worth anything, I'm using Fireworks to create and export my menu.
As is, I'm exporting my seperate files for my menu as .pngs, which seem to support translucent images, but I know that I'll be wanting to reduce the file size of these images soon, so is there a better alternative to getting a semi-transparent image other than using the .png file type?
Thanks,
Patrick
I'd say PNG is probably the best bet. The more modern browsers (read: not IE6) understand the 8-bit alpha channel it provides, whereas GIFs just have the transparency key.
Often these days, the bottleneck on sites isn't the size of the image (either in dimensions or in data) but rather the number of requests that it takes to load a page. More modern website designs try to pack as many images into one using techniques like CSS Spriting (woot.com, most of google). The other bottleneck is often not setting caching up correctly, forcing return visitors to reload a bunch of stuff.
You'll see google's various pages caching everything it can, and reducing the number of things a single page needs to download (combine all Javascripts into one, all CSS stylesheets into one) so that the browser is make 2 and 3 requests instead of 15-20.
I'd go with PNGs, and look into CSS sprites and caching as an alternative optimization.
See here for an example of an image sprite used on google's homepage.