i'm facing an issue which has been quite unknown to me.
In my example http://studio-a-h.de/kirby-test/projects/morning-has-not-dawned-yet you see a photoslider.
If you click on "Index" an overlay with the image index is about to be displayed.
In chrome and Firefox everything is fine, but Safari shows the overlay with a delay of appr. 500ms and it seems that there is an extra delay, even when the div is already visible.
Are there any known bugs with Safari and jquery? In my research i hardly found something, beside the iOS Mobile delay bug.
Would be great if someone has an idea. Maybe it is a css issue i did not find?
Best regards
Try and add a rule to adapt the browser in-advance, prior to that opacity change.
Use the will-change property like so:
.main {
will-change: opacity;
}
This will tell the browser that there is going to be some opacity changes to that div, so the browser can be ready for it before the opacity change rules are met.
Update:
It was not a jquery problem. I used hardware acceleration with translateZ(0) and this caused a super bad Safari performance on animations. Now i just have the problem that it lags like hell on scroll :(
Related
I have a Cordova 3.3.1 app running on Android 4.0.4 which displays images in a loop at 15 second intervals. I've currently implemented a crossfade solution as shown here: http://jsfiddle.net/chaddjohnson/ka9cqdnt/16/. This solution relies on two images layered in the same position, and the opacity of the top image changes from 0 to 100 (and vice versa) with each 15-second interval. This is the only page in the app.
Strangely I have found that if I include a CSS transition, the Cordova app will cause the device's memory to decrease over the course of an hour, and eventually the app will crash. Here is the CSS I'm using:
.ad-image:last-child {
-webkit-transition: opacity 2s ease-in-out;
transition: opacity 2s ease-in-out;
}
I'm absolutely sure this is causing the problem, as when I simply remove just these lines of CSS, the app works fine with no memory leak. And when I add the lines back, the memory leak comes back -- repeatably.
Does anyone have any ideas why this memory leak is happening? Is it a Webkit bug? Or maybe something related to my implementation (please see the jsfiddle)?
well i my self encountered this problem a lot. as the matter of fact i decided to disable every kind of effect. especially effects between pages. i think the problem rise from web-view. if you use android native code android will manage the memory and this sort of problems won't happen often. of course there are things that u can do such as disabling hardware acceleration but trust me it's still not good as what you want. my advise is to avoid any unnecessary effect as possible.
Can you try removing the :last-child property and assign a class (temporary) to your last element? Just to isolate the problem.
Is it the :last-child selector or is it the transition causing the memory leak?
Also, can you add -webkit-transform: translate3d(0,0,0); to your selector in order to activate hardware acceleration?
Native applications can access the device’s graphical processing unit
(GPU) to make pixels fly. Web applications, on the other hand, run in
the context of the browser, which lets the software do most (if not
all) of the rendering, resulting in less horsepower for transitions.
But the Web has been catching up, and most browser vendors now provide
graphical hardware acceleration by means of particular CSS rules.
Also, if it still doesn't work, try adding -webkit-backface-visibility: hidden; to your selector.
On the page http://bit.ly/1t9P8jS, when we scoll down the page, the fixed menu background color glitch. This bug occurs only on Google Chrome.
I change the Z-index, changed the .on('scroll') to a function on requestAnimationFrame, nothing repair it.
You can scroll down where it has 10 logos and go over the menu, you will see it.
What can cause this? Why it's only on google chrome? I never saw a background-color glitching like this.
Thank you very much for your help!
Set your .loader to display:none; this fixed it for me. (Chrome 38 on Win)
For whatever reason, Chrome must be confused by the zindex and opacity combination when deciding what to repaint.
It should be pretty easy to hide/show your loader instead of just changing the opacity.
I have a container div that holds about 20 more divs that float left. When I resize the parent div with a javascript animation using Tween.js the floats don't reflow to the new size unless I mouse over one of the divs.
It seems like something is preventing the page from refreshing.
I'm thinking maybe there is a way through javascript to force the display to update?
UPDATE:
I've put it on JS Fiddle:
http://jsfiddle.net/mattlundstrom/fNUhn/
Click any thumbnail to toggle the animation.
This version uses TweenLite to animate the "Left" CSS of the #project-container. Notice how you must move your mouse after the animation to get the container's contents to reflow.
I get this result in Safari 5+ OSX and Chrome 20+ OSX. Works as expected in Firefox 13.0 OSX.
UPDATE 2
Video of what I'm seeing:
http://f.cl.ly/items/1R1n2s0U3I3c1M3s2K0T/lundstrom_float_issue.mov
I was able to recreate your issue just as you said. It seems that it is an issue with webkit redrawing or measuring the elements after an animation or transition.
This isn't the best solution by any means, but for the time being at least it will work and hopefully what I found will help other people to be able to find out more.
If you add an onComplete to the animation, and trigger the .project mouseleave, it looks to work fine:
function completeAnimate(){
$('.project').trigger('mouseleave');
}
function contract(){
// PROJECTS CONTRACT RIGHT
TweenLite.to($('#projects-container'), .5, {css:{left:"300px", opacity:".5"}, ease:Expo.easeInOut, onComplete: completeAnimate});
}
So here is my jsfiddle which has a few tests and other animation tests so that you can see some of what I tried.
jQuery animate() and css keyframe animations have the same result as the Tween code you are using, HOWEVER, a straight style update works fine.
$('#projects-container').css('left','300px');
No issues with that at all, but of course, no animation either.
Some other things I noticed was that if you take out the .project event bindings, it still doesn't redraw correctly, however if you move you mouse it still doesn't. It simply stays that way.
I also tried forcing an element redraw using a few tricks you can usually use to force a redraw. I tried this oncomplete and at intervals after the animation begins, but had no luck with any of it.
You can also combine the two tweens into one with the properties on both, just an FYI.
Hopefully this will help someone find the true issue that's going on with the webkit transitions.
I have been using this site for awhile but never posted, I ususally found my anser.
However I seem to have a valid question regarding fading.
I have a simple javascript fade in script, with a functional cross browser opacity setting function. I am trying to fade in a large part of the webpage, but the large size or complexity of the elements in the div seems to really slow down the render in a couple browsers. In some browsers it works too fast, so I know the code works.
Does anyone know anything about the limitations of opacity rendering in different browsers?
I know I could overlay a simpler div with opacity but this just adds code when the existing code works, just not sure why there should be such drastic differences in the time it takes to apply opacity between the browsers.
jQuery has fadein/fadeout. Have you tried them?
I'm working on an example of a jQuery notification bar that you can see here: jQuery notification bar example
But for whatever reason the CSS I'm using to define transparency in IE 7 and 8 is not working. If you look at the example in IE 7/8, you will see that the transparency for the .png close button and the transparency for the "reopen" element does not work.
I've successfully defined an element's transparency in IE using this code before, but I can't figure out why it's not working in this example.
I thought I might have hit on something when I read this post, but after trying out the solutions mentioned with the hasLayout property I still didn't have any luck.
Any help would be greatly appreciated. Let me know if you need any additional details.
Thanks!
Wow somebody else just asked a question about this. In older versions of IE, you can't compose transparency from a PNG alpha channel with transparency from a CSS effect. As soon as you apply the style, it quits trying to do transparency from the image.
Yes, it's profoundly lame.
opacity: 0.50;
filter:alpha(opacity=50);
This fixes opacity for IE. Using 50% transparency as example value here.
As for the hellobar_close, give it a background-color and it should work. IE has poor support for transparency in .png images.
OK I believe that with the help of the answers provided above and some additional research on my own I have answered my question.
There are actually 2 parts to this problem:
1.) Transparency issues with the .png close button in IE - This part was answered by Pointy above. According to Pointy "The browser is incapable of managing the compositing of the transparent PNG concurrently with any opacity effect on the image. In other words, for any given pixel, you either get alpha channel effects from the PNG itself, or from an opacity filter, but not both." (Quote taken from his answer at IE7 and "jaggies" around layered PNGs (with jQuery))
What I want to happen is for the .png close button to be semi-transparent in it's normal state, and full opacity in its hover state, but apparently this is not possible to achieve in IE using only one single image and CSS transparency. So to get around this I'm just going to have to make a dual-state .png image to get a nice hover effect, rather than relying on CSS transparency to handle that component.
2.) Transparency issue with the "reopen" button - This button should be semi-transparent but did not work in IE. After doing some extensive research on my own I came across this post: jquery IE Fadein and Fadeout Opacity. woodstylee's answer in that post solved my problem.
Due to some weird IE bug that I don't completely understand, I need to declare the element's opacity using jQuery/javascript before any transition/fade effects are applied.
Obviously there is some kind of conflict with jQuery fades/transitions and CSS opacity in IE. If anyone else has some additional info on this subject please post!
When I updated my code with the following, I was able to successfully get my "reopen" button to appear semi-transparent in IE.
$('#hello_mini').css('filter', 'alpha(opacity=75)');
Note that the above line of code needs to be placed before this line:
$('#hello_mini').show('slow');
Also of note... this IE bug appears to only apply to the jQuery show() and hide() functions. When I switch the animation to slideUp() or slideDown() the transparency works fine without any additional javascript.
So bottom line... there is something weird going in with CSS transparency in IE when applied to elements animated through jQuery show() and hide()
If I find out anything else in my research I will post it here.
Here is a link to my updated example, which works in IE 7/8 now.