I'm resizing an image with setting the width/height dynamicly with css and using transform duration to smooth this process. However it is working but once the animation started the image gets pixelated. Occurs in Firefox and Chrome, i didnt test any other browsers.
Your height is fixed, before and after the resize, it could have something to do with it?
Try and amend the javascript to also set the final height of the div, if you want to maintain aspect ratio, see http://andrew.hedges.name/experiments/aspect_ratio/
from the initial 350x64 the final dimension should be 250x46
I'm using Swiffy to render onto a hidden canvas so that I can take the result and use it elsewhere. The problem I'm running into is that when I resize the container div for Swiffy it won't make the actual canvas any bigger than the available viewport size. If I set the dimensions of the Swiffy div larger than the viewport then the canvas will only get as big as the viewport - it doesn't want to put any part of the canvas offscreen.
I'm sure this is for efficiency, there's no reason to render something if it's offscreen normally, but I need to have Swiffy render it all the time, at whatever size I want.
Additionally, Swiffy just plain refuses to do anything if the Swiffy container div isn't attached to the DOM. (Forces the canvas to have a width and height of 0).
Is there a way around this without having to dig into the (obfuscated) Swiffy client runtime and modify it? How can I trick Swiffy into rendering larger than the viewport size?
Edit: I was actually able to trick swiffy into rendering larger than the viewport by changing window.innerWidth to whatever I want. That's a really ugly hack though and I hate to overwrite that as it causes a lot of issues.
If your swiffy runtime version is 7.3, you can hack the js directly.
Just remove or comment "b.xj(c);" in g.Tp() function. I don't care any advantage of offscreen rendering. At least, it works now.
I think it's a serious bug.
Note that it's good in iframe, no need to hack.
The only way I could figure out how to do it is to edit the Swiffy runtime and replace all instances of window.innerWidth and window.innerHeight with whatever size I wanted.
No ill side affects that I could see, though this is obliviously less than ideal.
If someone comes up with a better solution I'll absolutely accept it.
If i get the problem correctly, for rendering larger than the original swiffy you can put swiffy in a div and scale it
To have swiffy restrict to its original output scale as from flash, you can place it in an iframe
I'm working on a script and have an issue with Chrome.
Here's what I'm doing:
1. Loading large images into a DIV.
2. Scaling the images to fit the size of the DIV.
3. When the browser is resized, the image is scaled up and down with the browser.
Everything is working 100% in all browsers except Chrome.
I've checked the profiler in Chrome and don't see anything unusual.
These are large images, however are working just fine (even live) in all other browsers.
I've read a ton of places that have noted this issue when using down-sized images in Chrome...but not solution.
Nothing special going on, just using a
var img=new Image();
$(img).load(function(){ .... {);
Does anyone know of a workaround or solution that will work in Chrome?
Thanks!
So it appears that Chrome just sucks when it comes to handling large images and even images that aren't large, but just scaled down. I've searched around endlessly only to find similar questions without resolutions.
Still not sure why all other browsers (even IE 7 and 8) can handle large images (tested with 7mb scaled-down PNGs), but Chrome can't even manage to do a 700kb scaled-down JPG without lagging.
So, I'm answering this question with: in this instance, Chrome sucks.
I had exactly the same problem, but recently solved it. Huge amounth of performance takes up chrome's anti-aliasing, because it recalculates the entire image whenever you resize it.
So to solve it you just add this line to the css if your image:
#myImage
{
image-rendering: -webkit-optimize-contrast;
}
You can turn it off by javascript when the image is still.
More about anti-aliasing: Disable antialising when scaling images
How are you resizing the images? Using height/width or CSS transforms? The latter might result in better performance.
Some info:
Improving the Performance of your HTML5 App
When you're profiling issues with image resizes and decodes in Chrome, it's best to use the Developer Tools Timeline for this as it can give you relatively accurate stats on exactly what took a long time to be decoded.
Downsizing (or re-sizing) involves Chrome having to both decode the image (JPEG/PNG/GIF) you're sending down the line and then do extra work to resize that image into the container (div) that you would like to display it in. Where possible, the advice from the Chrome team is to prescale your images to the correct width/height needed.
Now you might be wondering: well, surely this issue is just down to desktop Chrome sucking, right? It's not as clear-cut as that. Particularly on mobile devices where browsers have less access to a powerful GPU/CPU, it's going to be costly to perform those resize operations there as well. So in short: yes, rescaling large images can be slow in Chrome sometimes. Try to prescale where possible and these performance bottlenecks should disappear.
I've been working on a slideshow script that uses CSS3 transitions, or jQuery's animate when they are unavailable. I've created a custom function to do the slide animations, which does so appropriately. Everything seemed to be working fine, but I've hit a major snag during testing.
For one reason or another, there is an large delay applying the jQuery CSS before and after the transition on large slideshows. For example, the slideshow in the link below is around 9900 pixels wide (container width, most of which is hidden). The container is maneuvered to display the appropriate slide, using CSS3 transition and transform properties. The delay occurs applying the CSS between lines 75 - 82 in the paste below. In particular, applying the 'transition' CSS causes the problem. Add the 'transition' CSS to the stylesheet (rather than applying it with JS), and delay disappears. This isn't really a solution however, because we only want to use CSS3 transitions on specific properties, that can vary (using 'all' in the stylesheet would transition some CSS that we don't want to animate, but change regularly).
Animation function:
http://pastebin.com/9wumQvrP
Slideshow Demo:
http://www.matthewruddy.com/demo/?p=2431
The real problem is with iOS, in which the slideshow (and even the browser sometimes) becomes completely un-usable. I can't pinpoint any errors, and have really exhausted my knowledge of debugging JS. I'm sure it is related to this section of the function after playing around a bit, and disabling CSS3 support within the plugin altogether removes the problem completely.
I'm completely stuck, and really appreciate any help anyone can give.
--- Edit ---
I've tried applying the CSS with native Javascript rather than jQuery's .css function. Same results, no better performance. Also worth noting that this isn't happening at all in Firefox, and seems to only be a problem with Webkit browsers.
Anyone with a solution, would happy to make a donation towards a few beers! I really cannot figure this out!
--- Second Edit ---
Ok, so been debugging and I can see that the slowdown is caused by the browser repaint cycle that is taking a very long time. Is there a better way to handle this that the way it is already doing? Positioning the element absolutely is a known way to reduce repaints, but that isn't really working because the slideshow is responsive. Absolutely positioning the slide images or the slides themselves causes it to collapse.
--- Third Edit ---
A day later, and I've made some progress. Adding 'transition: all 0s ease' to the elements stylesheet CSS has gotten rid of the repaint caused by adding the inline CSS transition property via the custom animation function mentioned in the original post. This causes a significant performance gain, especially when removing the inline CSS transition property when the transition itself has finished.
Good stuff! However, now there is still a slowdown when the inline CSS translate is being removed (that was used to create the hardware accelerated transition effect itself) after the transition, and the left positioning is being applied. When the two happen together, there is a slowdown.
Breaking them up into two separate tasks (the translate removed, then the left position added in a setTimeout with no time specified), again gets rid of the repaints = performance gain, and looks likes problem solved. But sometimes, the CSS transition property isn't get negated fast enough, and the translate removal gets animated. No good, and don't know where to look next to work around it.
I think the problem is you're loading HUGE images :)
They are too big for the container you have them in, so you scale them down, which is even more resource intensive.
Try resizing them.
First of all congrats for your debugging!
I have been working on the exact same stuff lately and found out that ios devices don't support a large number of images positionned in the same page. It causes crashes and the only solution I found was removing elements instead of just hiding them. The downside is that removing and appending elements causes lags so you have to do it cleverly, when your transitions are done. I thought the best way to go was keep 3 or 5 images in the DOM and replacing the rest with thumbnails of the images, resized to fit the original. When transitions are done, I'd just put the large images back into place...
Hope this helps you a bit on the ios problem at least...
After spending some time analysing your code TimeLine with Chrome Dev Tools, I believe there's some optimization you could do.
As far as I can tell, every single one of your 16 images gets fully repainted every time an animation is requested. This seems quite obvious to me, as there are 16 images in your example, and the Chrome Dev Tools reports 16 long "Paint" executions every time in hit "Next".
In my humble opinion, you should figure out a solution that considers only translating two images: the one you want to hide and the one you want to show. So, consider please, not moving the rest of the images and, instead, leaving them all side-by-side to the shown image.
One more thing, using scaled down images is probably making the paint cycles quite longer. Avoid them whenever you can.
Well, think I've managed to figure it out! Just so you know, original post links don't reflect the changes as I've done them on my localhost environment.
Absolutely positioning the slides container has fixed the problem that was occurring with repaint speeds after the transition had taken place (whilst applying CSS properties). Obviously taking them out of the DOM has done the trick, allowing painting to take place much more efficiently.
I originally didn't try this too much because I knew this would add a lot of work to the resizing functionality. I had originally intended to not resize at all in JS, and rely on percentages to do the dirty work. Absolutely positioning the container would cause the slideshow viewport to collapse, rendering the native resizing useless.
However, I was already having problems with sub-pixel rendering in other browsers anyway, so I guess it was time to bite the bullet and rely on fixed pixel values. I then used JS to handle the resizing, using the window resize event. All seems good, however the slideshow was still collapsed due to the positioning. Assigning height values wasn't working correctly, so was at a bit of a loss.
Thankfully, I came across a neat little trick of setting the 'padding-top' of the slideshow viewport to a percentage value, dynamically calculated (desired slideshow height, set in the settings panel for this script, divided by desired width). As padding-top percentages are relative to the width of the element, this did a great job of providing responsive height and correcting the viewport again (no longer looking collapsed).
Here is some info on using padding-top for responsive elements that maintain aspect ratio. Great little trick: http://f6design.com/projects/responsive-aspect-ratio/
All is good now, and things are working well in iOS and webkit browsers. Everything is extremely quick and working as it should. Four days later, and it is finally figured out. Not happy about having to resort to JS for resizing, but I guess it was always going to happen due to percentage inconsistencies between browsers. Lots of decimals = no good!
Thanks to all who tried to point me in the right direction. Definitely got me thinking, and learned a lot of debugging skills that I can use again to make sure transitions are performing well. Thanks again!
not sure if this helps or not but I noticed you use 3d translation - I would think a simple 2d translation would be enough especially since your third parameter is 0 and might accelerate the issue, also go with fewer images as Armel L. suggested, don't have an iphone to test though... alternatively, this is a solution I used before css3 but should still work move the element containing the images using javascript by modifying left (?and top - the demo only moves left and right though? without the transition effects) and this way you can fine-tune the refresh rate which I think might account for the slowdown... you can go as low as 18 fps without anyone noticing, might even be good enough with just 16fps
I had this when I was first designing a magazine carousel-style page device.
If you have a series of images within a long "tray", even if they are not within the viewport, they will still take up ram, and you can effectively have five or so before leaks and nastiness begin to happen.
What I found works is "hiding" them ... But make sure they take up the physical space necessary.
What I also found worked was that one could make the 'previous' current and 'next' image are visible and move the tray, 'unhiding' them as they reach those three positions.
In my own system, I skipped the 'tray' holding e images and only had them at -100% width, 100% width and the current one a 0.
I never had much luck with the typical long-tray carousel with large scale background images... Especially with css3 acceleration.
I have a script that lays out these circular icons on the map, you hover over them, they spring up, text appears, etc. The icons are scaled relative to their position on the map, ie, the distance from 0 on the y-axis. I've tried to set the scale through CSS's width and height attributes and through the html width & heights on the img tag and still have the same problem:
Basically, in their dormant state, such as when the page is first loaded, or the user flicks between tabs, the images (trans' PNGs) are anti-aliased. However, when the hover() function, and thus the animate() function, is invoked, the images suddenly become jagged and horrid. I've noticed that this behaviour doesn't exist in firefox but does in safari and chrome. I don't know whether this is to do with Webkit, jQuery or just javascript itself but maybe someone could shine some light as google resulted in nothing. Any thoughts? :)
Please also note that the bottom left and bottom right icons look fine in both attached screenshots- they're unscaled ones!
Thanks a lot :)
Matt
i can only guess on this, but my assumption is that gecko and webkit use different scaling algorithms for images. thus it has nothing to do with javascript, jquery or png at all.
in fact, the image still has antialiased edges even in the webkit screenshot. (you see that when you zoom in)
the border is just messed up which is usually the result of a bad scaling algorithm.
try the following to confirm this assumption:
<img src="youricon.png" width="90%" height="90%">
and compare the result in the two browsers. you should see the same problem.
possible solutions:
make a smaller version of the image and replace image with the smaller one on hover instead of scaling it.
use a scalable vector graphics format like SVG for your icons.