This is very strange. I am using SVG images, because of the low file size, sharp rendering, and scalability ( the objects animate quite a bit ). Its working perfect in FF, ie9, Safari and iPad, but in chrome certain SVG images are rendering very poorly.
Any ideas why this might be happening? The svg files themselves are very small.
Here is some a sample svg
So anyway, this is a legit chrome bug. And there is a fix, make the svg 'larger', svg files that internally report as too small cause this bug.
After many researches, I finally found a working fix:
export the svg twice the needed dimensions (I therefore named it filename#2x.svg)
then in css, add transform: scale(0.5)
The result in Chrome will look the same as in Firefox.
I've run into this bug too with an element wit an SVG background. The workaround was to reduce the opacity by .01, i.e.:
.thing {
background: url('my-image.svg');
opacity: 0.99;
}
None of the workarounds (opacity: 0.99, transform: scale(0.5), …) worked for me, so I went with this instead:
PNG#2x (twice the size PNG)
This seems to work well in all browsers.
The problem is as the graphic becomes smaller there are less pixels to work with. When rendering the SVG the browser is using equations to determine pixels but the equations result in numbers that fall in between pixels.
It seems the solution is to set the desired size of your SVG in your editing program and then make certain all of your pixels align to the grid. This will still allow your SVG to scale up but will also allow it to render at the smaller size.
Credits to: https://salferrarello.com/svg-looks-pixelated-when-small/#:~:text=Solution,render%20at%20the%20smaller%20size.
Related
I have converted a badge/image from PNG to SVG in order to be able to re-use the asset in various sizes etc.
The problem is that depending on the specific webpage i'm embedding the SVG on, it either looks super crisp (as intended) or looks bad with some sort of anti-aliasing gone horribly wrong.
Even on the pages where the SVG looks crisp after load, I only have to scroll the page a bit until it looks horrible as well.
Please look at the screenshots below to see the exact difference on the BADGE (SVG):
It seems the browser only messes with the SVG right where the SVG meets the image behind it. The SVG is only slightly transparent in the gray center, so that should not be the cause of it.
I have tested in Chrome, Edge, Safari which all do the same thing.
Does anybody know what might be the cause of this?
I found a fix to what clearly seems to be a somehow undiscovered big bug in all modern browsers in regards to handling SVG through CSS as a background on an element overlapping another element with background/image.
The fix for my case was simply adding a background-color to the element. Since the element is completely round I can simply make a border-radius as well, so the background will never appear.
If the element however was not a complete round circle, this would not be a workable fix.
It looks perfect in chrome and firefox, but the scaling in IE and Edge is terrible. The size is good but the image looks sharper, the actual image is 2 times bigger than the background size. Is there a way to fix it, I've tried several things I found on stackoverflow but nothing seems to work.
The problem is your relying on the browser to resize your images. Browsers have notoriously poor rendering when scaling images. You should use a specific size and pre-format them in a graphic package beforehand.
I would also consider using an SVG for what you are trying to achieve (I assume the scaled down image is so that on different resolutions, things still look good?) I would seriously consider the flexibility it would give you.
Over the past week I've been helping a friend experiment with SVG-based sprite sheets in the browser. We wanted to come up with an ideal workflow to prepare, publish, and run high-quality animated graphics in the browser. So ideally have a single source of animation data that would work for small smartphone screens, tablets, retina displays, and desktop browsers.
In theory, (vector-based) SVG should be ideal for that, but since SVG is not usually used that much - we decided to test it out. The idea was not to use SMIL SVG (so no SVG-based animation) but instead create an animation sprite-sheet (as you normally would with raster data PNG/JPG) but do this with pure vectors i.e. SVG. Its was a bit bigger but if it works this - it would work even with something thats even more optimized.
Plus frame-by-frame vector animation could do great things for our workflow - it would allow us to use the Flash editor to do the animations and then export them to SVG sprite sheets.
Anyway, the result works surprisingly well but also fails in some areas (please note for test purposes we only worked with Webkit-based browsers i.e. Safari, Chrome, mobile Safari on iOS, and Android ICS).
In CSS it's pretty easy to trigger hardware acceleration for a sprite sheet like this (at least in modern browsers with keyframes and steps) - you simply do this:
background-image: url(my.svg);
-webkit-animation: walk 1s steps(12, end) infinite;
to call keyframe-based animation shown here:
#-webkit-keyframes walk {
from { -webkit-transform: translate3d(0, 0, 0); }
to { -webkit-transform: translate3d(-100%, 0, 0); }
}
where the use of translate3d should let GPU kick in and the entire thing should be hardware accelerated in iOS mobile Safari and Android ICS browser.
Surprisingly enough considering that it's kind of a brute-force technique and a fairly large vector animation (600x600px for the test) - the whole thing flies. But its not perfect - it flickers in Safari before taking off. And in the ICS browser its flickering all the time so its not really usable.
So we tried the usual tricks to get rid of flickering such as:
-webkit-transform: translateZ(0);
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
But that didn't work. So then we tried rasterizing SVG dynamically in memory and using it as a texture with -webkit-transform: scale3d(1, 1, 0) but that didn't help ether.
Finally we just replaced the SVG with a rendered out PNG/JPG sprite sheet of the same size thinking the complex vectors are just too much for the browser - but guess what? Its the same issue - so its not SVG rendering at all - its a browser drawing issue. A further proof of that is if we slow the animation down to 1FPS - flickering still persists.
Is the image just too big for GPU? Have we reached the performance limit of what you're able to comfortably draw/animate in the browser (mobile in particular)?
I would really appreciate ideas/hacks on how to potentially get rid of the flickering (especially since its performing sooo fast). Its just a promising technique - hight performance browser animation that adapts to different screen sizes - the HTML5 Holy Grail ;)
With a few optimizations such as
<svg preserveAspectRatio="xMinYMax slice" viewBox="0 0 600 50">
and some CSS magic we're able to have the SVG adapt to its container perfectly and change its size from a single CSS class. It really would work wonders - but alas the flickering.
Anyway - please read more about it here where you're also able to try it out.
Pretty cool idea.
How about changing the zindex of the frames so you are layering the images on top of each other? This might solve the flickering because during the redraw the last frame is still visible. So, you'd just keep increasing the zindex value of the latest frame. Of course, there is a limit to that and you'll need to reset the zindex again, but it might have a big impact on cutting down the flickering.
I don't have ICS here to check it out, but on iOS 6 on an iPhone 5 and Jelly Bean 4.1.1 on a Galaxy Nexus the animation looks pretty smooth, except when I zoom, at which point I get a few flickery frames and then it settles down again.
Which reminded me of a similar issue I was having rendering onto a large canvas and transforming it around the screen (with the majority of the canvas offscreen at any given time).
My black-box analysis at the time suggested it was some optimization where the browser wasn't bothering to render offscreen content, instead waiting until it became visible, which completely defeated the purpose of having the large image and hardware-accelerating it around.
My "solution" was to -webkit-transform: scale the entire image down small enough to guarantee it all fits onscreen (so the browser has no choice but to render the entire image), let it render, and then scale it up to the size I wanted.
(As an aside: to hide this hackery from the user, I initially experimented with setting opacity: 0 so the pre-render wouldn't be visible, but it seems this had the same effect as offscreen rendering - it got optimized out. In the end I set the opacity very low and covered it with an almost opaque "loading" message, meaning the background rendering wasn't visible to the naked eye, but the browser had no absolute visible/invisibles to optimize out. Not sure if this was overkill, but it seemed to work for my setup.)
I'd be very interested to know if a similar technique might work for you.
I am optimizing my site for these higher resolution monitors (especially the new iPad). I have the site formatted the way I want, and I was just increasing the resolution of each image but still constraining it to the DIVs that I currently have. For example, I have an image with a resolution of 483x246 and I have it fitting a DIV with a set size of 188x96.
The images look great on Chrome, Firefox, and most importantly on the new iPad. Even zoomed in it's nice and crisp (as opposed to my old 188x96 image that looked blurry and pixelated when zoomed in)
The problem comes in when I open the page in IE. It displays the image at the correct size but it's jagged. See link to comparison below. I know it's an issue with the way IE resizes and renders pictures on the fly.
My question would be, is there a way to make IE display the picture nicely? If not, is there a way I can put in the code so that if it detects IE, it displays my old low res image? I've looked everywhere but haven't found anything that relates to my specific problem. I know this is a small example but my bigger images do the same thing and are more noticeable. I hope you all can help. Thanks. :)
Comparison:
Have you tried putting this in your CSS?
img { -ms-interpolation-mode: bicubic; }
There's also this https://github.com/adamdbradley/foresight.js which looks very interesting
Make sure IE9 isn't in compatibility mode or IE7/8 mode...
The reason this happends if because the bitmapdata is actually rendered completely different in the IE browser, the thing IE does is it "cuts" away pixels over a set ratio so like every 5 pixels it yanks a pixel and therefor makes it look like it misses certain gradient properties.
not much you can do about this except for keeping the aspect ratio set but I guess you would've known that by yourself already
I am working on an infographic with sliding carousel <li>s, but the SVG is showing up pixelated in Firefox, even though the bug with SVGs in FF has been resolved, I thought. Can anyone see a fix for this?
URL: http://weaver-wp.weavertest.com/radiation-infographic/
You are zooming your SVG file to a very large size:
background-size: 9730px 30000px;
background-position: -7310px -29250px;
Most browsers will not antialias very large SVG shapes, as it requires too much graphics memory. (This is what we see in Safari and Chrome.) It looks like Firefox is actually rendering the SVG to the size of the canvas and then blowing it up with image interpolation to your cropped region.
The fix for both is the same:
Crop your SVG first and use just the cropped portion as a background.
Use the viewbox property of the element when panning/zoooming. It is much higher performance and simpler to use.