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];
Related
I'm facing a problem I can't figure out how to solve. I'm almost sure this is a Chrome bug since in other browsers it works like a charm but I want to be sure. On my website, developed using a mobile first and responsive design approach, I have a menu that uses the Left Nav Flyout pattern. On Tablets and desktops, I show it full width.
When I load the website on my smartphone (specifically an Android device) using Chrome in Portrait mode, once I rotate the device (passing in Landscape mode) and start to scroll the page, as soon as I reach the menu position, the latter magically disappears. What is really strange is that if you try to click the space that now is completely white, you can see that the links are actually there. I tried to use the inspector to find the problem but didn't succeed.
So, wow can I solve the problem? Anyone else had this issue before? If you know it's a bug, I'm glad to add a temporary workaround as well.
I didn't find a real solution but a reasonable workaround. Of course, I still hope that someone will explain what's the cause of this issue and how to solve it.
In the meantime, I found that the problem occurs because the menu, 240px wide, is completely out of the viewport. In fact, as soon as I changed the margin-left to 239.5px the menu didn't disappear anymore.
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 a UI where the navigation is over a blurred set of images (blurred using webkit blur), and whenever the navigation moves, theres this strange almost ghosting effect that happens. After you click away onto another element, the ghosting also goes away.
Any advice on how to solve this?
On Mac Snow Leopard:
Chrome 19.0.1084.56
Safari all of them, including 6 beta
It seems that you are encountering a browser/engine dependent issue.
Chances are : you can't solve it by yourself aside from not using blur, or the like.
Not that this bug might not impact all users, depending on the version of the webkit they are using.
Hopefully the problem will be corrected in a future version. Maybe try to contact webkit guys, but that's really all you can do (aside submitting a patch).
This problem is only happening in Google Chrome on Mac OS X (Chrome 17). I've tested it on all the major browsers on Mac and Windows 7.
Here is the page in question:
http://dealsfortherich.com/drop/
As you can see, I'm loading divs via JQuery AJAX.
The page is always fine on "Refresh."
You can navigate pages with the left and right arrows. The problem happens when you change pages; especially when you change pages when scrolling the page quickly. Try scrolling the page down very fast and hit the right arrow.
The background images that were already loaded via CSS (for example):
.sort_block{ background: url(images/sort_block.png) no-repeat;}
start to disappear. Only background images that are loaded with CSS start disappearing. All are fine. If you open Developer Tools on Chrome inspect the elements, you will see that the browser has the correct syntax and it has already downloaded the image into its cache. For some reason, it's just failing to display it. The CSS display value is correct. In the Inspector, for the div with the missing background, if you modify a value such as "top: 8px;" to "top: 9px;" the image suddenly appears.
This is only happening in Chrome (v. 17) and Chrome Canary (v. 19) for Mac OS X (10.7.3).
Should I report this bug to Google or is there a known work around or fix? I guess I can replace the s with s but I would rather do it correctly and fix this weird issue.
I don't know if this is the same issue, but the root is probably the same: http://code.google.com/p/chromium/issues/detail?id=111218. Based on that report, I don't think there's a known fix yet.
I had the same problem and diagnosed it for hours, but it's not about your code, it's a memory related bug in latest chrome. In my experience it doesn't happen to small images, so a temporary solution would be to decrease the file size (to under 10kB or so).
I have a test file here, showing the difference between a big and a small background image.
http://kolina.fi/chrometest.html
We worked up a solution for this issue until Chromium/Chrome "fixes the glitch" (hi, Milton)...
My colleague, Andrew, posted our solution here:
http://blog.andrewcantino.com/blog/2012/02/15/fixing-the-chrome-background-refresh-bug/
You can see the page in question at:
http://www.mavenlink.com/tour
It sounds like this has worked for others as well, but it's ugly!
I've recently had this issue, and the fix was to use the complete url, rather than a relative path.
E.g. change url(images/image.png)
to
url("http://yoursite.com/images/image.png")
Use :url(.//images path. The .// should solve the problem.
Why do elements with the CSS position: fixed applied to them cause Firefox to eat 100% CPU when scrolling the page they are in? And are there any workarounds?
I've noticed this behavior on a few sites, for example the notification bar at the top of the page on StackOverflow. I'm using Linux in case that matters.
This is bug #201307.
It's a bug reported in bugzilla
Apparently a work-around (with mixed reports of success..) is to disable smooth-scrolling
Just disable smooth scrolling in Edit > Preferences > Advanced.
As already stated, this is bug #201307. The workaround is to disable smooth scrolling:
Edit -> Prefrences -> Advanced -> General tab -> uncheck "Use smooth scrolling"
This website has a fixed element "First time at Stack Overflow? Check out the FAQ!", and it's slow as hell in firefox. Works better with Opera and Chrome though.
FF3, Windows XP, ATI.
it eats CPU because the browser has to repaint the entire viewport every scroll change rather than just the newly visible area
Are you sure that there's a direct link here? Have you created a static HTML page with fixed elements to verify your theory? Given how widely these CSS properties are used, I'd think someone else would have noticed it by now, whatever browser/OS you're running.