I have 10 absolute layered background-images. Their sizes are set after the size of the viewport. When the viewport is made large some layers disappear and show up as white blocks. I have only seen this in Chrome. Chrome doesn't seems handle this layered element as well as other browsers on any device. I am using transform: translateZ(0) for GPU acceleration. In other browsers (FF, Safari and IE) the web app performs without this problem. The problem seems not to be affected by the file size, but rather the paint areas.
Does anyone know why this is happening in Chrome or how to fix it?
I am running windows 7 and google chrome 30.
This is a problem with Chrome's compositing engine. I have an active bug report with the Chromium developers. Hopefully, it will be fixed in a timely manner.
Bug report: https://code.google.com/p/chromium/issues/detail?id=346621
Related
Hi I have this problem on font spacing for different OS on Chrome.
This is the screenshot from MAC Chrome,
http://awesomescreenshot.com/0382ihbwa3
This is the screenshot from Windows Chrome,
http://awesomescreenshot.com/0752ihdi26
Is there anyway to make them look the same?,
I don't have any problem with slight differences on content spacing on MAC vs Windows but this one affects the Main nav sections alignment.
Any help would be really appreciated, thanks!.
Chrome will soon be transitioning to use DirectWrite for font rendering, instead of GDI. This means it'll be able to use proper subpixel rendering of webfonts, like other Windows applications (inc Firefox and IE). It's a known bug that has been around for a long time: https://code.google.com/p/chromium/issues/detail?id=124406.
You can enable DirectWrite rendering now on Chrome Beta/Canary, but it's at the price of security because sandboxing is disabled. It's nice to know it's coming though: https://code.google.com/p/chromium/issues/detail?id=137692#c109
So I made a site that heavily relies on CCS3 animations, I would never do this for a client as I know it is risky but as its just a personal project I don't mind.
The animations work fine on modern browsers using Windows 7 and they seem to work on XP when using Firefox, they don't work at all on IE but again it's a small personal project so I do not mind.
Now when using the site on the latest Chrome with XP the animations work but not correctly.
When you click the div, the div flips over displaying information, but on Chrome/XP it just flips the div but just shows the same div, just backwards instead of showing the other div behind it.
Also when using Chrome/XP it shows some of the images backwards when you load the site up, which I assume is the animations not displaying correctly.
You can see the site here: http://www.dansteeds.co.uk/awipmapv2/
Any help or information is greatly appreciated.
Chrome uses gpu hardware acceleration to render 3d css.
type the following url into your chrome browser http://chrome://gpu and check for 3D CSS: Hardware accelerated. If it isn't, it will instead use a kind of quasi-3d isometric projection.
I think the hardware acceleration might be disabled in your browser causing a bug in your animation.
:)
I have an issue with Chrome mobile where some text is rendered in bigger font size than it is in CSS. I checked in developer tool and find that those text have inherit the correct font size, but still rendered 5px bigger in the computed style.
I find this post Fix font size issue on Mobile Safari (iPhone) where text is rendered inconsistently and some fonts are larger than others?
but -webkit-text-size-adjust doesn't work for me here.
I have checked in different mobile browsers including Dolphin, Opera Mobile and Safari, all rendered the text correctly except Chrome mobile.
Update: Solved, it caused by the setting of Chrome Mobile to render the text bigger. I don't think this is something we can block in the setting.
The issue is that between Chrome Mobile 18 and Chrome Mobile 25 the rendering of fonts changed. It appears that the Chrome scaling feature at 100% is actually up scaling the fonts. We had to set the Chrome scaling feature down to 85% to get the fonts to not upscale.
Also it appears that if we touch anything on the web page the fonts on the page re-adjust to the proper size. This shifting between scales is VERY concerning as it affects applications is an extremely negative way. Especially if you are attempting anything that needs to ensure any psychometric validity.
We've run into an optimization problem using WebKit on Mac OS X that we're hoping someone can help us with.
We've written a Cocoa app for Mac OS X that essentially manages a single WebView that points to our online web site. Everything is working fine for the most part. However our web site uses CSS's position:fixed to keep a thin "header bar" locked to the top of the WebView, similar to the big orange "Welcome" bar at the top of StackOverflow.com. We've determined that with position:fixed active, scrolling the WebView forces the entire web page to re-draw itself, which causes scrolling to be agonizingly slow. With position:fixed disabled, scrolling is very fast and fluid; only the page elements that are scrolled "into view" need to be drawn.
We know that this isn't a bug in our Cocoa app code, nor is it a problem with our HTML/CSS code. The same slow scrolling occurs using WebKit test code from Apple. We can point Apple's test code to http://www.StackOverflow.com as a test and we see the exact same behavior. There's also a test page in the Mozilla bug database that we've been using to test the problem (https://bug201307.bugzilla.mozilla.org/attachment.cgi?id=139911). The odd thing is that some WebKit-based browsers on the Mac (eg, Safari and Chrome) don't have this problem; scrolling is always fast on pages using CSS's position:fixed with those two browsers.
Has anyone else experienced this problem with WebKit on OS X? If so, what can we do to speed up our scrolling? Thanks.
I might be way off here as I'm not sure if the same will apply in your web view, but using a style that forces the nav onto its own layer may help.
Something like translateZ(0), or translate3d(0,0,0,). I've come across similar issues when building with Phonegap and applying some thought to layering really helped out.
I believe the browser can utilise hardware acceleration where a third dimension is involved.
I was having a similar problem: the fixed bar was flickering when I was scrolling the page.
So I forced the WebView to use layers and I fixed
[w setWantsLayer:YES];
I had a similar issue in my webview based mac app. It has header and footer with position:fixed css property. Latest webkit shipped with 10.10.x and above don't suffer from this issue. It happens in webkit for mavericks (10.9.x). I got it working by setting these properties for the webview
[self.webView setWantsLayer:YES];
[self.webView setCanDrawSubviewsIntoLayer:YES];
Should i check in all? or in any one is enough because all share same rendering engine Webkit.
My question is related to HTML CSS rendering.
I know one difference Safari for windows and MAC both have Font smoothing (anti -alisaing)
Is there any other differences?
There's definitely a difference between Chrome and Safari due to Safari's font rendering. In Safari text tend to be a bit bolder due to the anti-aliasing algorithm and can sometimes take up a few extra pixels on the screen.
Also keep in mind that Safari uses the SquirrelFish javascript engine while Chrome uses V8.
I have found a difference in the way Safari and Chrome select SELECT boxes. I think Chrome seems to ignore line-height whereas in Safari line height seems to make a difference.
Safari Windows 5.1.7 v's Chrome Windows Version 22.0.1229.94 m
I think this is to do with the default user agent style?
I would check, yes.
Whilst the browsers all use the same rendering core, they're not necessarily on the same version (and there are multiple versions of Safari out there in any case).
Also, as slebetman says, font rendering is quite different depending on OS and anti-aliasing settings too, so you need to be aware of that.
Shadows are fast&ugly in chome; slower&prettier in safari (and firefox). IIRC there was some difference in CSS3 transitions too - but really, these details are still in flux anyhow and change from version to version.
In practice, I only check one of the two regularly, which is generally fine. Before putting major changes online, it's obviously not a bad idea to check again, but during development, it's not worth the hassle; they're so similar anyhow...
There are major and minor differences. Do check!
Minor: full support for CSS3 border-radius in Chrome. I've read about, but can't find, this in Safari.
Major: zooming in Chrome zooms everything. (This is the behavior in almost every browser.) Zooming Safari zooms text but leaves other things unchanged. Your ever-so-carefully-laid-out form is highly likely to be trashed if the user zooms in. Leave lots of extra space.