I have been search for hours for a jquery type plugin that is responsive and also has proper swipe animation during gesture.
http://www.photoswipe.com/ is 99% there except that it dosent support single image lightbox mode, its geared towards grouping images into swipable galleries, which it does brilliantly.
However now and then I may want a few images on a page to have no relation to each other. Id rather have a default class, that when used all images opened up in a single image lightbox. Photoswipe automatically groups any images given the same class.
If I was able to set an option with this plugin to hide the prev/next images on a call, then it would have been perfect.
Important though, is that the plugin must use full screen like photoswipe does. So many responsive plugins seem to waiste the screen with unrequired image chrome. The intended slide show or light box should be like viewing a gallery on a smartphone - again photoswipe does this. its only fall back in being able to have non related instances.
There are a couple out there that appear to be inline with what you want. I never understood why some developers create "responsive" galleries, but waste so much space with padding or decretive chrome elements.
I was thinking of using PhotoSwipe, but the developers stopped supporting it and recently threw it out there for the open source community to maintain. Kind of turned me off during the transition.
Here are a few others I came across that I'm considering myself.
Need higher rep to post more links....so some are just cut and paste. Sorry.
JuiceBox
(http://juicebox.net/)
SwipeBox
(http://brutaldesign.github.io/swipebox/)
(full disclosure...I have an affiliate code for the next links. If you want to remove them, just don't add the "ref". If this helps, I appreciate the clicks)
Touch N Swipe
(http://codecanyon.net/item/touch-n-swipe-image-gallery/5886023?ref=bmoe)
Flare (wow)
(http://codecanyon.net/item/flare-responsive-mobileoptimized-lightbox-plugin/2392703?ref=bmoe)
I have a website (http://file-new.com/client/vequity5/). The whole website is in the jQuery Malsup's Cycle2 plugin. Everything seems to be working fine and as expected except one little thing. When you click on the last page (contact) the slide transition has a little white flash. It's more pronounced in safari that any other browser but it's still visible almost any browser. My observation of the effect are leading me to the conclusion that it has to do something with the synchronization of the animation of the slides.
Any advice/thought will be much appreciated.
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 been redesigning my WP portfolio website of late and have been playing with a neat little aesthetic jQuery plugin, BlackAndWhite, Which turns all of the images in my gallery view black and white and makes them recolor on hover using the HTML5 canvas.
I noticed one bug with the plugin is that if it runs before the images have finished loading, it will sometimes only grey-scale half of an image. So I have been using another tiny plugin to only run the script after I'm certain that the images have finished loading. see waitforimages.js
The initialization script is the following:
jQuery(document).ready(function(){
jQuery('.bwWrapper').waitForImages(function(){
jQuery(this).BlackAndWhite({
hoverEffect : true // default true
});
});
});
where bwWrapper is the wrapper around each img.
Now this works really nicely on most computers and browsers that I have tested thus far. Everything works the way it should. However, when I opened the site on my android, I noticed that only 50% of the images recolored. When I refresh the page, again only 50% go black and white, though it is different ones each time. Making the site fully responsive to mobile is still on my to-do list, but I have noticed this fairly blatant, yet difficult to explain bug.
Any idea what might be causing this?
You don't need to preload the images because the plug in aleady do it. Try to download the last version of the script on github https://github.com/GianlucaGuarini/jQuery.BlackAndWhite and if you still have problems send me a private mail with a link so I can check what could be the problem.
Here is my site: http://www.dreamweddinggroup.com/redesign and I'm having a hell of a tough time figuring out why in gods name my fadeIn, fadeOut and corner() functions won't work in IE8. They were working for a time, but now they have broken and I can't for the life of me figure it out. Can anybody see anything that would cause the problem here?
To see what I'm talking about, if you were to click on the "About Us" link at the bottom of the page, you should see the text fade in. Then if you were to click on "Why Dream Wedding Group", the "About Us" text should fade out, and when it fades back in, you would see the new text.
Hey I was having the same trouble. I was trying to fadeOut an IE image and fade something new in like so :
$(".edit_photo_link").click(function(){
$(this).fadeOut("slow", function(){
$(this).next(".throb").fadeIn("slow");
});
});
Which wasn't working. But the FadeIn was! So guessing that this was processor getting eaten up by IE8 (not IE7), I just changed it to this :
$(".edit_photo_link").click(function(){
$(this).fadeOut("slow", function(){
$(this).hide();
$(this).next(".throb").fadeIn("slow");
});
});
And IE8 users don't get that extra loving of animation.
I had similar problems with a stack of absolutely positioned divs. I wanted to simultaneously fade one out and fade one in. Code that worked fine in FF/Safari would not work in IE8: The fadeOut() wouldnt fade, only the fadeIn().
I found solution was to use CSS to set the z-index of the element to be faded-in to be at the top of the stack:
$('#fadeoutdiv').css({zIndex:90}).fadeOut(2000);
$('#fadeindiv').css({zIndex:99}).fadeIn(2000);
I'm finding that IE8 has terrible performance using fadeIn myself with just a small image or text area. I think the engine is basically very bad at alpha blending! Because you're trying to fade fullscreen images, the performance is so slow that you just don't see the fade. In my case, I'm seeing CPU usage rocket to between 50% and 100% even on fairly powerful desktop with a decent graphics card. My client is having problems because every time this fade happens (every 5 seconds or so), video that is also playing starts skipping and being generally unstable.
Another site I'm working on is http://www.urstreams.com , if you hover over the boxes you will see a description appear also using fadeIn. If you mouse over all the boxes at once, so all the descriptions are appearing and disappearing at the same time, all the animations grind to a halt and CPU again rockets skyward.
Bit of a nightmare really, but at this stage I would recommend against any alpha blending animation in IE. The common theme in all these cases seems to be that blending is occurring over images. Perhaps this is the problem, as common jQuery samples and possibly tests / benchmarks tend to focus on basic scenarios such as plain text appearing over plain background tests?
I too have noticed this phenomenon with IE 8, though it seems to occur no matter what my element is floating above. I had an empty 4x4 px DIV that i was fading in and out on an interval (interval at 400ms, then element.fadeIn(100).fadeOut(500)) to debug element positioning and it was completely obliterating one of my cores! It took me a while to figure out why IE was constantly hitting 50% CPU while Chrome and Firefox barely broke a sweat -- I figured I had a rogue greedy loop somewhere until I scanned across my interval.
Fire up IE and your task manager and head over to http://www.hv-designs.co.uk/tutorials/jquery/all.html for a little test. Sort your running processes by CPU desc and watch IE rise to the top on every test (20-40+% of my 1.2 GHz dual-core Intel SU2300 for the duration of the fade +/- a few hundred ms), even for the simple text paragraph! Running the same test in Firefox or Chrome doesn't even break 10% usage for me.