I've got big problem with SVG smoothness on IE 11 (works perfectly on Chrome).
It should work like real-time timeline. SVG element is dynamically increasing it's height, events are shown in it's time and goes down all time. The problem is that moving elements by 1px is visible and looks bad.
On Chrome I resolved this problem by adding transform: rotate(360deg) (now also I've got scale()) which enabled antialiasing for these elements, and now it's working smoothly there.
Animation on IE isn't smooth unfortunately. I tried positioning elements both by x/y and translate(). Position is calculated precisely each time requesting animation frame. It's more visible on raster images included into (or I just think so). I tried using shape-rendering, text-rendering (for text) and image-rendering for these images.
There is simple JSFiddle: http://jsfiddle.net/9ke74mqo/
Has anyone any other idea?
Thanks
If anyone is interested I've just resolved it. The problem is that in IE there isn't any possibility to turn on antialiasing by any svg element property. When I packed everything in <g transform="rotate(360)" /> element everything just works fine.
Related
This is driving me mad, I can't figure why a simple <circle/> is rotated at 180deg on IE and Edge.
It looks like a bug of the browser, but I can't let it that way.
Maybe you know a CSS hack that can fix the issue because this is only a problem of CSS update in the viewport.
The proof: when you click on the circle - in IE, not Edge - it returns back to its normal rotation (but the js doesn't affect at all the rotation of the circle...)
Here's the demo (at the bottom) : http://charraire.dev.adelios.fr/notre-organisation/
Compare with Chrome / Firefox and IE / Edge and you will see the big difference.
If someone could help me he'd become my savior!
Hehe... Actually I solved it by trying to do a jsFiddle.
The fact is that IE and Edge have trouble updating the SVG properties with javascript if they aren't already declared (in the DOM or the CSS).
I explain myself:
I have several <circle/> elements in my DOM and they all have r, cx and cy attributes.
I give them stroke and stroke-width directly in my CSS.
Then, with javascript, I update their stroke-dasharray and stroke-dashoffset.
But IE and Edge don't like when you update these attributes with javascript IF YOU HAVEN'T SPECIFIED THEM IN THE FIRST PLACE (God knows why).
So my solution was simply to add stroke-dasharray="0" and stroke-dashoffset="0" in the <circle/> elements. And magic! It works!
Or, even simpler, I just added stroke-dasharray: 0; and stroke-dashoffset: 0; in my CSS, and it works too.
Hope that it would help someone else.
I am trying to animate lines going from left, right, top and bottom(lines should start from edges of the screen). Animation works fine in IE11 but not in Mozilla and Chrome. Other browsers I haven't tested. I used Adobe Illustrator to draw. http://codepen.io/Ljanmi/pen/WbyLWv
In Chrome and Mozilla(IE11 is fine and acts normal) if in Illustrator I set Object>Artboards>Fit To Artwork Bounds(minimizing Artboard size which I usually do when create or edit SVG) I get this result(even worse) - http://codepen.io/Ljanmi/pen/yyqVqz
I spent hours and hours trying to figure out on my own without success. I started topics on GSAP forum and CSS tricks forum(stackoverflow.com is limiting me to post only 2 links as a newcomer).
I used GSAP JS library for animating(generally very happy with GSAP) but animation behaves the same if I use CSS3 to animate. I concluded that it is not related to GSAP(viewbox size property seems to have little bit of effect here) , more likely to be related to SVG structure itself or browser compatibility or both. So I guess there must be some work around to make it work like I would like to. I most likely lack some SVG/HTML/CSS3 knowledge since I am not very experienced but trying to learn as much as I can. Thanks everybody for reading.
Add svg { overflow: visible } and it should work the same in all browsers (longer explanation below). If you want to see why the lines get clipped, add borders to the svg element.
Another way is to make sure the size of the svg matches what you want, e.g by using css.
All browsers except IE implemented hidden as the initial value for the overflow property for the <svg> element, as called for by the SVG 1.1 spec. SVG 2 has changed this for (outermost) inline svg elements, such that it requires what IE11 is currently doing. It will take some time before that gets changed in all browsers, so for now just add the overflow: visible rule and it should work correctly in all browsers.
I had some trouble with browsers still not showing the overflowed content for SVGs and found that this finally got past it:
svg:not(:root) {
overflow: visible !important;
}
I am developing, just for fun, a jQuery plugin that reveals elements from a "stack" as you scroll down the page.
Github repo is here - https://github.com/JayBizzle/Reveal
Demo is here - http://jaybizzle.github.io/Reveal/
Everything works great in Chrome, but when testing in Safari I am seeing some weird rendering issues.
If you view the demo in Safari and scroll down fairly quickly, you will notice white gaps appearing between the coloured DIVs.
Even stranger is, if you then inspect one of the out of position DIVs, the inspector highlights the DIV in the correct position. Also, if whilst your in the inspector, you change one of the elements CSS attributes, like adding a border, the page gets redrawn and the element appears in the correct position.
Anyone got any ideas if this is a Safari bug, or something i can overcome with some little known CSS?
I had a similar issue.
My workaround was giving position static first and then relative with a bit of delay.
$(elem).css('position', 'static');
setTimeout(function() {
$(elem).css('position', 'relative');
}, 1);
I'm using d3.js to draw a (multi)line graph (with quite a few data-points, 1600 to be exact) on an svg element.
This graph is in a container which has a transition on it.
On a certain event the container gets moved 400px to the top with a CSS3 transition which works fine in Chrome. When trying in Safari and Firefox I noticed that is was really slow. After some checks I can say with 99% certainty that the svg element gets redrawn during the transition (a lot) in Safari/Firefox (and possible other browsers, too).
Is there anyway to prevent the browser redrawing it constantly until the transition is finished? Or maybe other solutions that would make this fluent?
FYI: not drawing the chart in the SVG element makes the issue go away, so I'm certain the slowdown comes from the SVG element.
The simplified html code:
<div id="container" style="transition:margin 0.75s; -webkit-transition:margin 0.75s; ">
<svg id="simple_line" style='height:210px; width:100%;'/>
</div>
Generally speaking, using margin or any other CSS position value to make objects move around the screen is sub-optimum. Try using a transform/translation style to create the movement, which will tell the browser to use graphical optimization methods.
The idea is that a transform tells the browser to move around a block of rendered content, instead of re-calculating the whole layout. Results will still depend on the quality of the browser's implementation -- as you discovered, Chrome has good optimization either way, but this should reduce the browser-to-browser differences.
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.