We've developed a web application that shows quite a bit of data in a somewhat fancy interface with a table. I can't show the page, but it has quite a big table, inside a fixed positioned element, with some images (mostly icons smaller than 2KB, PNGs with alpha transparency, and no more than 30 different images).
It's not that heavy, with less than 1000 elements in the page. It was developed mainly in Chrome, and works flawlessly in Chrome. And IE11, and IE10.
But when it comes to IE9, this happens:
Yes, that's IE11, because it offers decent analyzing tools. I'm using IE9 emulation, but that same unresponsiveness happens with IE10 in IE9 mode, and with "native" IE9, with high CPU usage - but steady memory usage.
In a lighter way, it happens in IE8 too:
But the repainting takes much less time (perhaps it repaints smaller parts of the page?) and the responsiveness isn't compromised.
As you can see, no script is running, just some random garbage collection. In IE10, IE11 and Chrome there's no repaint involved.
If I disable the images (did this in IE10, don't know how to do that in IE11), IE9 doesn't keep repainting, but if I disable or hide all the images through the style sheets it keeps hogging the CPU. Disabling hardware acceleration makes things even worse, as expected.
What may cause this odd behaviour in IE9 (and partially IE8)?
After a lot of investigations, I think I've found the culprit.
It seems to be a problem related to animated GIFs. Whether it's a <img> element, or set as a background image, or as the content of a pseudo-element, even after it was removed from the DOM the browser keeps on repainting the same portion of the page.
This can be a very intensive task, not only in older computers, especially when using larger GIFs. But even when using smaller ones, if the GIF is used as a background image or in a pseudo-element, IE9 repaints the whole area of the element, rather than just the area of the image.
That's why it keeps on repainting a huge area of 1750x1051 pixels in the screenshot. And I just used a crappy 64x64 spinner!
So... beware of spinners. And IE9.
Solution
I haven't found a simple and definitive solution yet (except ditching IE9 altogether). The first thing to avoid is using animated GIFs in background images and pseudo-elements.
If you have to show a spinner in IE9, you can either use a small one, or a static image. Alas, you have to animate it yourself because IE9 doesn't support CSS animations. And you can't rely on requestAnimationFrame either, just setInterval.
I just hope you can take advantage of jQuery. I couldn't...
For some reason, IE8 deals with animated GIFs much better, even if it's still not perfect.
Related
Background info: I'm working on a public facing website for our company. developing in VS2012, asp.net and vb.net, using some JS, some JQuery, and a decent amount of CSS.
Everything was looking great in our internal testing, until someone checked from home, where they only had IE 9. Suddenly, big chunks of text within expanding panels weren't being displayed, the bottom of the page was missing in most cases, some links that call javascript functions don't do anything... It's so random that the only reason I think they're connected is that it only happens in IE9 (or probably before, though no one has looked.)
I tried setting the standards mode to edge in the web.config. (tried setting it to IE10 as well, just to try) I've played with changing some positioning, heights in px instead of %, relative to fixed positioning, tried inserting the html5shiv, removing the gradients... nothing has changed. Everything displays correctly, until it doesn't display at all. When I was starting to see and research this last week, I thought I'd found an article somewhere that said there were limits on the CSS tags you could use in a page for IE9, but that number was WAY higher than anything I'm using, including both what's on the page directly, and incorporating the .css file. The only other clue is that it looks like at the bottom, where the missing stuff starts, I also lose the gradient from the page background (so just a block of all white, however if I play with the size of the window, sometimes I can get this block to slide down, and I can see another line or two that was originally hidden...
Has anyone had issues like this? The site works perfect in chrome, ff, IE10 and 11, several Linux browsers, opera, safari, from macs, pcs, and Linux boxes. everything except this old IE 9.
HELP?
Just a little hack fix I found, if anyone comes across this question looking for similar answers... I created a new css file implemented when IE9 browsers are detected, and I extended the min-height for the content of pages until every page displayed... the drawback is that on those longer pages, if the content isn't expanded, the footer still lies several scrolls down... but this only happens on the very content-lengthy pages, so while it isn't ideal, I guess it's good enough, if someone's ok with using outdated browser technology :/
For some reason, black boxes are displaying in random spaces in Chrome (latest build).
Some of these boxes are appearing outside of the main container, whereas some are appearing inline, covering content blocks. They appear randomly, usually after scrolling, and will often disappear when opening the inspector, hovering over elements, or scrolling down and back up.
For reference, there are some animations, box-shadows (which have been disabled with no luck), linear gradients, and position: fixed elements on the page, although this is not an issue with browsers other than Chrome.
This has been widely reported in user testing, although I have not been able to conjure up a fix. I am not sure if it is a CPU or graphics card issue, as the site is relatively lightweight and I am browsing with a new laptop with 16gb ram. My old Mac Mini, with 4gb of ram, does not produce this issue.
Any pointers would be most appreciated.
Update: This was a bug in Chrome and was fixed: https://code.google.com/p/chromium/issues/detail?id=142038
eddz filed the issue at crbug.com/new and over 40 people starred the ticket to follow along. It led to a few separate fixes in Chrome by the engineering team.
I had this issue with a website that was using transformZ (0) to force GPU rendering. When I removed this style the issue disappeared
This isn't an answer, but if you are able to somehow reproduce it maybe later on down the road:
Make a copy of the page locally, or anywhere, set the base href to the main domain, now start removing css links and js scripts from the bottom to the top until you don't experience the behaviour anymore, if you get to that point then the last script/stylesheet you removed is the culprit.
If you find the culprit file, now try finding the culprit line/section.
If you don't get to that point, it may be the browser, but it doesn't sound like it is.
It may also be linked between scripts/stylesheets and/or accidentally inherited.
We had experienced this weird blocks too on our website. In past we was using transitions, transitions was reproducing another bug "weird lines" randomly appeared on page and dissapear during scroll.
Now we start using transformX-Y, may be in some places Z too. And we have got this hell bloack blocks.
It seems something wrong in Chrome with transfom + transition animations. May be this bug appear when too much blocks animated at one time?
FF works fine.
I encountered these same boxes. For me, the problem was that I was using mp4 videos, which are deprecated in chrome, instead of webm videos.
I think is related to the GPU I had the same issue on my website. And it stopped happening when I turned on the Metal Rendering flag.
My website renders back bgs randomly while scrolling. It is really heavy on videos and animations and looks like chrome has so little GPU available that graphic intensive website doesn't work correctly on blink. I noticed that when chrome used webkit those issues didn't happen.
I this is a blink render issue.
I want to test my html page visually in every browser like chrome FF and IE, like the position of all the elements and padding and margin in the page is correct or not.
Now what I am doing is I open the page in two browsers and I cascade the two browsers side by side and I compared it with my eyes.
Now my question is : is there any tool or plugin available to test the page by overlapping the page in IE with the same page in chrome or FF so that I can find any difference in visual representation of the elements, so that I could correct it.
Just like screen shot comparison (in screenshot comparison I can't compare the entire page and moreover I can't overlap one screenshot images one over another)?
This is the wrong way to go about it. Attempting to get each browser to match pixel-for-pixel is a futile endeavor and only leads to frustration, code bloat, and wasted effort.
Design for the valid browsers (typically the Webkit ones and Firefox). Then fix, as needed for the others. But don't try to get things to mesh pixel for pixel.
I'm doing HTML/CSS/Javascript development on iPad. I'm using css transform to translate gallery elements (li elements within an ul). The li's contain text. It all animates fine on desktop, but on iPad 2 device the animation phase makes the font somehow less bright, and when animation is completed the font returns normal. The difference is really visible, almost like going from regular font to bold and back. As said, it all is well on desktop safari, only happens on iPad mobile safari.
Anyone having the same issue?
.pom.
I've seen this and other slightly odd behaviour which is down to hardware acceleration for 3d transforms but I haven't found a single standard 'fix'. In order to try better to understand the problem, take a look at tips here:
http://davidwalsh.name/translate3d
and here:-
How to force re-render after a WebKit 3D transform in Safari
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