Please have a look at this: http://www.eymy.nl
The transition works smoothly in all browsers, but becomes jerky in Safari when the images are scaled down (when the window height is smaller than 1227 pixels, which is the 100% height of the images). In other words, Safari cannot handle this transition together with scaling.
My guess is that it CAN, but needs different code. I tried different slideshow scripts and the results are always the same, the moment the images are scaled (down OR up) the transition in Safari becomes jerky.
Any advice will be greatly appreciated!
I'm using Chrome and Safari on a i7 MacBook Air and it was smoother in chrome. After the first image loaded in Safari which was choppy it looked OK. Since this seems like an issue of images loading before they are animated I would suggest preloading them. This is usually done in the body tag with JavaScript or you can also use CSS. See this page for ways to preload images.
Related
We have a website whose background is a stack of images through which we go with JavaScript.
We check whether the next image is loaded before switching to it, and it works fine on Chrome, Safari, IE, and all mobile browsers, however on Firefox we sometimes get a white flash.
This problem also happens if we make sure that all the images are preloaded so it's not a problem that FF shows the image before it has finished loading. I've seen the question asked elsewhere but from the user's perspective, and the solution was to disable hardware graphics acceleration, which does not solve completely the problem but reduces it. However we obviously can't ask that from our users.
Similar problems were reported in other questions:
jquery animate (height) causes background-image flickering in firefox
Image Flickering only in Firefox
Firefox background image flickering when using multiple instances and background-size
skrollr background image flicker in Firefox
However none has a clear solution. Does anyone know how to correct for this?
Cheers!
I've developed a simple click game where you click an image and it gets replaced by another image. The first image is faded out and the next image is faded in using jQuery/animate/toggle.
After each animation the anti-aliasing on all images is lost for a second. It then reapplies anti-aliasing to all images.
Is it possible to force anti-aliasing constantly or force it to refresh faster so there's no time where images are not anti-aliased?
For me, in an embedded WebKit on Mac OS X, using this (non-standard) CSS works to preserve the antialiasing of images during CSS animations:
img {
image-rendering: optimizeQuality;
}
This may not work for other browsers, of course. The mozilla.org site claims that this behave as an alias of 'auto' but it definitely changes the behaviour in WebKit.
Scroll through the images in Firefox (tested on v. 26) and you notice if you look to the right that the image stretches one pixel (or so) after its .src has been changed. This behaviour only occurs in Firefox and if the width of the image is increased or decreased by 1px (through web console), the behaviour disappears... I know that the image is bigger than the width I set but it still doesn't explain the behaviour and why it's only occuring at a very specific width (after all, image is still resized in browser if I increase or decrease the width by 1px as well but then the behaviour disappears). Works perfect in Opera, Chome, Safari and IE...
http://www.mosaikdesign.se/galleri_.php
Anyone?
I spent some time researching this and they way I see it, it's a bug.
I filed a bug report at Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=953364
I also made a thorough test page for those interested in studying this behaviour: http://www.blackwinged-angel.com/bugs/index.html
And finally, the fix:
-Set css property image-rendering on the image to something else than auto (optimizequality, optimizespeed, -moz-crisp-edges). It's claimed in the documentation that optimizequality and optimizespeed are the same as auto (https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering) but they do result in different downscaling algorithms being used (see my link for proof). However, this fixes the problem.
-Use image sizes where images are only upscaled, not scaled at all or check the resulting downscaling since it only applies to certain sizes of the containing element in relation to certain actual image sizes, not all.
Again folks, this only applies to Firefox, was tested on Firefox 26, applies to downscaling images on-the-fly in the browser by styling img (and possibly other) elements with width and height and it's not consistent (just happens at about roughly 30% of tested downscalings on a specific image for me).
I'm having issues with a parallax site I am building using Skrollr.
I've built a site that has the same effect as https://www.spotify.com/uk/. The effect being large full width background images that move slower than the natural browser scroll, and have text and other images moving on top of them.
When viewed on a desktop browser the site functions fine and performs perfectly. The problem I'm having is when testing on an iPad (iOS 6.1.3) and you release your finger from the screen and Skrollr's intertia animation takes over, the large background images and other content on the screen start to jitter and jump on the screen. This does not happen when you still have your finger touching the screen and scroll, only when you let go and the easing takes over.
A couple of things I've tried are:
Setting webkit-backface-visibility:hidden on all of the background images, and skrollr-body div.
Animate elements using –webkit transition: translate3d
If anyone could shed any light on why I'm getting this page flickering issue that would be great.
I had a very similar issue (i.e. Skrollr / iOS parallax background image 'flicker'). I believe you'll find it's related to this: cubiq.org/you-shall-not-flicker
Simple solution (from the article): -webkit-transform:translate3d(0,0,0).
In my web application I frequently have sections that need to be collapsed/expanded. I do this with jQuery using the slideDown() and slideUp() methods. They work great. However, in Firefox, if I am scrolled all the way to the bottom of the screen and I collapse a div the screen stutters and flashes as the div disappears and the page is automatically resized by the loss of the element.
Has anyone run into this problem before? I've been working around it by setting a min-height with a generous amount of space for any section that will be collapsible but this seems like an unnecessary solution. Chrome doesn't have this problem and, amazingly, neither does Internet Explorer, both of which smoothly resize the page without any sort of stutter or flashing.
I'm using Firefox 3.6 on Ubuntu and I've experienced this problem on earlier versions as well. I have not tested on Firefox 4.
I have ran into this problem before and yes. I have worked around this by setting a mini-height or consider not using a slide effect.