I would like to know, does anybody have any experience what would be better:
1.) Using spritesheet and drawing it on canvas element.
2.) Using spritesheet with normal div and moving spritesheet via js or css.
Thanks, Luka
Moving sprite-sheets with CSS is generally faster as most of the logic is done internally by the browser in compiled code, while doing it in JavaScript adds an overhead due to JavaScript itself.
You won't be able to avoid JavaScript completely of course, but reducing the amount of calls through JavaScript helps performance (in general, and this is also why you probably want to avoid jQuery for this specific purpose as jQuery comes with an overhead of its own).
With canvas you have more options in terms of altering the sprite-sheet, but if you don't need this I would recommend you use CSS and plain JavaScript where needed.
Related
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.
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.
Referring to the kind of look of the images seen on this site - http://sl.dream-theme.com/html/albums-light.html (I'm in no way involved with this WP theme, just providing an example). The author is using jRaphael to create "path cuts" which is a nice and browser-safe approach, but I'd like to avoid including an additional library solely for that purpose.
very basic:
http://dabblet.com/gist/2874826
uses css pseudo elements to mask the image (pretty descent browser support -- will render as a square image in legacy browsers, probably nbd?)
If shadows / borders / things are needed you could add and additional wrapper to fake the slanted borders using more pseudo elements or a manipulated (transformed) box, or something.
I'm working on a site with lots of CSS3 transitions (which are hardware accelerated) and high memory objects (for example, an array of 39 objects, each containing the full html source for a typical online news article) and I'm noticing some very choppy/jittery scrolling, which I've been unable to debug.
I've kept these high memory objects out of the DOM, which should prevent them from affecting DOM performance, however, I can't help but think that they are still having a negative effect. I don't have code samples to post because I'm unsure of whether this is even an issue.
Please go to this site (Orange) and click on an article tile. In the reader div that pops up over the page, try scrolling as you normally would. Does it feel choppy/jittery? Do you have any suggestions on how to improve this?
CSS3 transitions, opacity, text and box-shadows and the like are certainly known to impact rendering speeds. In fact, even sites with heavy use of text-shadow alone can cause choppy scrolling on the average computer. Combining this with heavy use of javascript seems like a recipe for choppy web browsing.
edit: The loading animation on the o in orange is pretty awesome!
Yes, that's jittery. A page with a lot of Javascript will do that and frameworks like jQuery won't help at all. I'd recommend recoding as much as you can without using jQuery and passing it through JSLint (http://www.jslint.com/).
Try using Chrome's developer tools too to get an idea of what the bottleneck is.
Try disabling Javascript too and seeing if it's any better. If it isn't, then you know where your problem lies.
See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.