I've noticed that, when repainting filled SVG paths (due to color/opacity changes triggered by mouse event handlers, for instance), the repaint is sometimes glitchy on Chrome:
I haven't seen this behavior in Firefox, Opera, or Safari (haven't tested IE yet.)
Any ideas on how to fix this? Some more details: the SVG in question is generated by d3, and makes heavy use of <use>, <clipPath>, and <g transform="...">; the screenshot you see uses CSS opacity rules, but I've seen the same thing from updating the fill color in CSS or JavaScript.
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 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.
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 have a page where necessary elements are repositioned over some extra html attributes.
For example:
<div class="contentplate" relativePosition="top-left" relx="1" rely="3" relw="14" relh="8" relFontSize="80"></div>
is repositioned by class 'contentplate'. It is positioned to a raster related on the actual windowsize. It's child elements are processed recursively to get the relative positioning also working inside this containers. All of this works as expected.
The trouble begins when using jQuery('parentcontainer').animate( {left:0},100 ) or something:
in some way repositioning the elements leads, jquery to animate only the parent element and not the childs.
the funny part is after te animation is done, the position of the childs is corrected somehow by jQuery but as told not animated.
All the elements are styled position:absolute, overflow:hidden
and no, the repsotion algorithm only runs if the window is resized, or after the page has been loaded once.
I have 3 Test for you if you are interested:
the site fully dynamically repositioning (animation is failing, except in firefox)
http://www.bourier.org/demos/jquery_animation_failure/test_2.html
a snapshot of a repositioned site without active repositioning (all browsers, all good)
http://www.bourier.org/demos/jquery_animation_failure/test.html
a fully dynamically repostioning site with a yellow grid you can see enabled
http://www.bourier.org/demos/jquery_animation_failure/test_3.html
a screenshot where you can see the dynamic page with grid enabled
thanks for your time
As it seems, it is a bug in the browser Engine correlated to usage of a canvas and CSS modifications of div's z-ordered above.
The canvas is there only for checking the grid features are correct e.g. debugging purposes.
I removed the canvas and everything is working now as expected.
There is something very wrong, can be shown here using the chrome developer tools:
The elements are detected in the correct position by the debugger, and mousepointer, but they are not displayed there. very odd this.
i don't want to digg deeper than this, but in my opinion the Firefox behaviour is correct and Chrome and Safari are doing something very wrong.
If i should post a issue report to chrome developers leave a comment and i will.
I'm having a problem using the jquery hover events. I've created a reduction of the problem. You can find a working demonstration here. I can reproduce this after moving the mouse around in IE, FF, Opera, and Chrome.
I'm using queued animations in my mouseover event. Roughly 1% of the time, the color of the td elements is left as #0f0 after the mouse has left the td though. This should not be. The mouseout event should guarantee that eventually all tds turn back to #00f after a time has passed.
Update 2:
I've now reduced this probably about as far as it will go. No mouse events used at all. It's started working better in Opera, but now IE is a total cluster.
Anyway, I'm using a button to trigger this:
function ani() {
$('td')
.stop()
.animate({backgroundColor: '#0f0'}, 3000)
.animate({backgroundColor: '#00f'}, 3000);
}
See it here.
Update [n + 1]:
I just can't leave this alone. I've determined that the animation actually is occurring. It's just not automating the background color. I've done this by adding text and animating the background and foreground in unison. Under normal conditions, you should never see the text once it starts animating, but sometimes the background gets "forgotten", and sometimes the foreground. This indicates to me, that a jquery animation is actually occurring, but it is just not animating all the attributes it was instructed to. For the curious, see it in action here. (warning: IE chokes pretty hard on this)
Ok, going to play some video games now.
I don't understand how you get your 1% figure. I'm not sure about what behavior you're seeing, but in both FF3 and IE8 I get this ugly illegal-property-value error as documented here: http://dev.jqueryui.com/ticket/4251. More relevantly, a good dozen of them aren't changing colors, even if changed to simply a single-color animate.
Fixing that line in the jquery.color.js and both FF3 and IE8 work like a charm, although IE8 white-screens, it recovers eventually.
jQuery is great for managing the DOM, not so great for effects. In my experience, the UI stuff is painful to use and has always had issues. The framework itself, though, has always treated me well.