I've been experimenting with pretty complicated SVG backgrounds (via CSS, fixed, 100% size) and it makes both FF and Webkit based browsers slow to a crawl, to the point it's impossible to scroll.
Would you have any idea how to improve the speed of it?
I investigated a big PNG (slow to load, not as "smooth" as SVG) and Canvas without much success.
The site in question was here. Now it incorporates canvas method.
All the elements on the site are vector-based so it can scale to whatever device there is.
So it seems that all popular browsers render page/scroll much faster when the complicated svg background is applied to an underlying canvas (or img) then if it was applied to the body element itself.
Still looking for suggestions how to make it work faster, but at least now it is usable.
This background is very complicated to render on the fly, so I believe that SVG is not feasible. You will have to consider one of the following solutions:
Use a pre-rendered background (i.e. a png background).
Use a simpler SVG, with less elements. In your current background the browser will have to render each line individually.
Related
I'm using Normalizr to display alternate PNG background images, where SVG is being used, for older browsers.
The no-svg class is being triggered, however, there are some strange results: background sizing properties set on the backgrounds are lost on some elements, but seem to be retained on others. Furthermore, I couldn't use shorthand to set this (having to write separate declarations), but I imagine that's the browser's fault.
I need to control the sizing, especially because the layout is responsive.
If you have any ideas, please do reply.
Thank you for your time.
I'm looking to use CSS gradients for an element of my web app that is drawn repetitively, as it would allow me more flexibility in dynamically changing its appearance. However, my question is whether gradients are more expensive for the browser to render than bitmap images. Or do images use more processing power? (And I'm not concerned with cross-browser compatibility- the app will only be used on the iPad)
According to an article on the Webkit Wiki, images perform better:
Sometimes it's tempting to use webkit's drawing features, like -webkit-gradient, when it's not actually necessary - maintaining images and dealing with Photoshop and drawing tools can be a hassle. However, using CSS for those tasks moves that hassle from the designer's computer to the target's CPU. Gradients, shadows, and other decorations in CSS should be used only when necessary (e.g. when the shape is dynamic based on the content) - otherwise, static images are always faster. On very low-end platforms, it's even advised to use static images for some of the text if possible.
Source: https://trac.webkit.org/wiki/QtWebKitGraphics#Usestaticimages
Of course, you have to balance that CPU time with the extra time it would take to load the image from the server. Also, for Internet Explorer, filters are extremely slow, especially if you have many on one page.
This above answer is directly lifted from How does the performance of using background-gradients in CSS vs using images?
These links can be useful read for you
Browser Repaint/Reflow performance: using CSS3 Gradients vs PNG Gradients
CSS gradients are faster than SVG backgrounds
http://leaverou.me/2011/08/css-gradients-are-much-faster-than-svg/
Runtime Performance with CSS3 vs Images
http://jacwright.com/476/runtime-performance-with-css3-vs-images/
Is there any way to make ie (7,8) display a gradient AND a background-image on the same div?
The only way I got it working (but only almost) was by using two filters, one for the gradient and one using the AlphaImageLoader - but of course, then you can't position the image.
Declaring a background-image and gradient filter doesn't work, because it simply won't render the image - only the gradient.
Is there any (preferably non-js) solution to this?
If not, I'll have to resort to using a background image for the gradient as well, which isn't quite as nice but won't make much of a difference either...
I would say that adding a little unnecessary markup is the lesser of the evils here. Either that, or let IE-users live without the gradient.
Oftentimes getting your design to work is a trade-off between semantics, performance, standards and pixel perfection. Accepting that fact was hard for me, but it's made me a better front-end developer - I can work faster, and I can make decisions about what metric is important in a given case.
I have an zoomable image in the website. When the image is zoomed out to a large extend it appears very SHARP and ugly.
I tried using image-rendering : opimizequality, optimizespeed CSS but did not work.
Is there any other way out.
Thanks
According to image-rendering on MDC, image-rendering is currently only supported in Firefox 3.6. A similar property, -ms-interpolation-mode, is available for IE7 and IE8. Other browsers don't seem to have this feature (yet).
As latze mentioned, your best bet is to edit the image itself, scaling it to the level you need. I'm not sure, but you may try using <canvas> to perform the interpolation you desire.
I would simply edit the picture instead of the CSS.
Try making the picture slightly larger step by step while you make sure the picture doesn't (as we call it in danish, not sure if it correct english) "pixelate".
This can be done in various image editing programs from The Gimp-shop to Photoshop.
Images aren't meant to be resized that much. Think about an image as a graph where each pixel is a single square in the graph. If you stretch the image out, you're essentially making the pixels stretch out. Some programs try to fill in these pixels with what they think would fit there, others just make the pixel bigger, and others just fill in the surrounding areas with the same pixels to give it a sort of glowish effect. Resizing images down, while it tends to work better, also creates the same effect, because you're just chopping off pixels instead of adding them. Most programs that I've seen will squish pixels together, combining whichever colors were in those pixels. If you have a high detail image, then chopping off pixels is going to make it look horrible. There are no really safe ways to determine which pixels need to be retained to keep the overall image in tact. Most websites that have zoom features have a much larger image which has been resized down and they let you zoom to view the details of the larger image. Some even get separate images of the massive detailed one and the smaller preview one.
I've tried jquery.pngFix.js and pngfix.js and neither seem to cater for all issues.
Any images that are anchored end up distorted with the former and the latter doesn't like positioned/repeating background images.
Unfortunately the design I'm working on calls for PNGs to be used in the way I have done, so I'm not really sure where to go from here?
google for DD_belatedPNG - this is the best one I have seen
You can check out this site for a decent fix:
http://www.greyhats.com/tech/a-better-ie6-png-fix-37
I have used that successfully, with some caveats. You can't make the image tile, which is a deal-breaker for some uses.
The ways I deal with transparent pngs and IE6 are:
Make the transparent color of the png the background color of your site. Works best for things like rounded corners, drop shadows and elements that overlay the background only.
If the background is a gradient or image, replace the png with a gif in your IE6 stylesheet. This is very easy if you are using sprites for background images. The rounded corners may not be as smooth in IE6 as other browsers but I consider that an acceptable trade off.
If I really need a javascript solution, I use DD_belatedPNG