I realise this is a bit off shot, but I will try.
I have never experienced anything like this before - I am building an accordion for the page, and when I expand it, random lines appear below the expanded item (see image).
The most visible line is a separator and should be there, however I have no idea where the other ones come from. This quirk is not replicated in Chrome nor Mozilla.
Moreover, if I do not have web inspector opened and I open it, the lines disappear. This leads me to believe it might be some issue with painting the DOM element, possibly the mentioned border-bottom?
Anyone has ever experienced anything like this before? Being the perfectionist I am with OCD, I find it extremely annoying!
Add to your animated element:
transform: translateZ(0);
to enable Hardware accelerated animations.
Safari will then remove those residual liny glitches.
Also -webkit-backface-visibility:hidden; might help to remove edged lines that usually appear in Chrome (if you apply rotations...).
Related
In Chrome DevTools, under Rendering, there's an option to "Show potential scroll bottlenecks".
When I enabled this, some div elements I have on the screen with overflow:scroll show a flag at the top saying "repaints on scroll."
I can't find a lot of documentation on this feature, and I don't know whether it's something I can actually fix or improve upon, or just a statement of fact - the divs have content, and they do indeed scroll.
You can apply this CSS on the div with overflow: scroll or overflow: auto that create scroll bottlenecks.
transform: translateZ(0);
-webkit-transform: translateZ(0);
That will force the browser to create a new layer to paint this element, and sometimes fix scroll bottlenecks (especially with Webkit).
Although the accepted answer solves the problem, it is worth looking at the CSS will-change property. This is preferred over transform: translateZ(0); in recent times. Here is an that article explains the difference in detail - https://dev.opera.com/articles/css-will-change-property/
.scroll-container {
will-change: transform;
}
This amazingly took me multiple days to track down what was going on, and only because I saw the one side-comment at the end of a bug report at
Chromium bugtracker Issue 514303. Here's what's going on and how to fix it:
There exists a concept called "LCD text", which I believe means subpixel antialiasing, i.e. "crisper sharper text". Unfortunately, this feature is mutually incompatible with compositor-accelerated scrolling.
LCD text is enabled by default (at least on Blink/Webkit?) on all platforms which are not high-DPI (most normal monitors; i.e. you can check console.log(devicePixelRatio)). On the other hand, LCD text is DISABLED by default on high-DPI devices (think Retina display, or most mobile devices and tablets) since you don't really need a "crisper sharper text" feature on high-DPI platforms.
Therefore the opposite is true for compositor-accelerated scrolling: it is only possible on high-DPI platform where LCD text is disabled.
However, you can force compositor-accelerated scrolling on most monitors by promoting the overflow:scroll element to its own layer, by either adding will-change:transform to that element, or any hackish equivalent which will force the overflow element to be the parent of its own layer (such as transform:translateZ(0)). (Do note that vendor prefixes are being removed.)
tl;dr: Chrome doesn't suppose both subpixel antialiasing AND gpu-assisted scrolling; pick one or the other. Subpixel antialiasing is the default pick on Chrome (except on cellphones and retina displays, because their text is so small you don't need the feature, so you won't notice this issue on those platforms). Override this by forcing the element into its own compositor Layer with will-change:transform (but note that maybe your text won't look crystal perfect).
Nope, you cant modify that, it is a Chrome function to allow you to know, what's painted each update in the window.
Updates can be a lot of different things (scroll, mousemove, interval, requestanimationframe,...).
But, now you know that, you can enhance your code.
If (I dont know), the browser alway re-paint a div if it is set to overflow scroll you maybe can do some JS to set to overflow hidden when out of screen...
This post talk about different Browser layout
I just found out about this really cool plugin (new for me, old for some of you maybe) and it works like a charm upon implementation, but only in regular computer browsers. When I try it on my android phone, the css3 animation of the dropdown moves really really choppy, just like its dropping frames. How can I fix this problem?
Here is the plugin I am reffering to:
http://responsive-nav.com/
They seem to have done a really nice job with the plugin, I would say the largest cause of the drop of frame rate may be because you are repainting the entire screen. If you would like, roll your own side navigation but make it go over the existing web page rather than move all the elements on the screen.
EXAMPLES OF SIMPLER MOBILE NAV without repainting
http://fringewebdevelopment.com/
http://www.sony.com/index.shtml
As a further step you can also get rid of the javascript and just do plain CSS and see how that works for you, an example of using checkboxes and labels to control the side nav can be found on my site (just inspect the code) - www.aktof.ca . Hope this helps!
I am using text-shadow for all p and headline tags (2px white glow for better readability), everything works fine until page is scrolled and javascript changes absolute positioning on one element to fixed - which I want to stay visible.
Is there any way apart of changing style for opera to make it scrolled smoothly? overflow:auto is not working in this case...
Thanks
it's hard to say 100% without seeing the code, but I guess that the way you've styled this page makes Opera do a lot of reflowing and painting when it is scrolled, and the combination of styles will make this a very expensive operation. (It would be nice to see a jsfiddle or get a link to the actual page, this would also make it simpler to advice on possible workarounds).
There are various fixes you could try - like keeping the element you want on-screen styled with position:absolute and move it from JavaScript after scroll events, or simply avoid setting position:fixed in Opera and letting the element scroll away for better scroll performance.
However, I'd strongly recommend that you first report a bug to Opera. Why?
The reason and the genesis of the web is collaboration. It may not be obvious to (understandably) frustrated web developers struggling with browser bugs, but they have a responsibility for helping browser vendors improve when they find problems, thereby contributing to moving the web forward. A minority browser like Opera admittedly has less development and QA staff resources, but to some extent support from the user community and "normal" web developers makes up for this and makes it possible also for smaller players to develop in the Web ecosystem. I think that's one of the web's strengths and the real reason why no single corporation has been able to dominate it.
So please report your issues and problems :)
This is a problem with Opera, not any way you've written the code. Opera is a gigantic steaming pile of doo-doo with almost no market share, and you should use another browser.
That's basically all anyone could tell you here, unfortunately. I understand that everyone loves their browser of choice but some just don't handle these things well. Other examples: browser with a poor javascript engine rendering animations erratically and jerky, etc.
I'm developing a product to be used by a number of customers alongside our Web application.
Quick background:
These customers have incorporated into their pages a widget that we've developed.
The widget's content can be modified by using our application.
The idea behind this product is a bookmarklet that we supply, which will "highlight" our widget on their page, turning it into a clickable link that leads to an administration panel in our app.
The "highlight" effect actually involves some z-index tricks; we create a semi-transparent "backdrop" <div> just a few ticks below the maximum-supported z-index to gray out the page; then, we adjust the z-index of our widget to sit on top of that translucent backdrop. The visual effect should look about like this:
http://skitch.com/troywarr/dtexp/example-good
However, in Safari, as well as Firefox under certain conditions, there seem to be some sort of rendering artifacts that prevent this from looking as intended:
http://skitch.com/troywarr/dteqx/example-bad
As you can tell from the screenshot, a couple of elements (our logo image and the <iframe> that holds an advertisement) are still "bright," as intended. But, the rest of the widget is still shaded-out.
I've been poking around with Firebug for quite a while to try to get at the source of the problem, but I haven't had any revelations. I'm hoping that someone has experienced a similar issue, or recognizes the "visual signature" of this kind of problem. Or, if you're simply adept at JavaScript/jQuery and/or Firebug, I could really use your help trying to figure out where this approach is falling short.
I created a test bookmarklet as a live example. To see it, please:
Open Firefox (the version under development currently only works there reliably).
Go to this page and drag the link there to your Bookmarks Bar: Example Bookmarklet
Navigate to: http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2010/07/30/sports/s170637D86.DTL
Click the bookmarklet while on that page, and you should see what I'm referring to.
Thanks very much in advance for any help! This has me baffled.
I was about to give up on this, but I think I found the problem. You have a hell of a lot of DOM elements going on here, but luckily that isn't the issue causing this problem.
The iframe inside DIV#onespot_nextclick needs a background color of #FFF.
Simple!
This may sound crazy, and i didnt believe it until i saw it for myself.
The vertical scroll bar does not scroll when you click in the space between the scroller or the arrows. You have to drag the bar to get it to scroll. This only happens in the ugly default theme (not windows classic).
The scroll bar has some heavy javascript behind it that drive scrolling of another DIV on the page.
Has anyone even encountered this before? Why the heck does the theme influence IE's rendering?! Only IE!
edit:
this problem happens when you are in "non-classic" XP theme (the default ugly one). switching themes does not cause this, but it does fix it if you switch to classic from the default.
Does it help when you add
<!--[if IE]><meta http-equiv="MSThemeCompatible" content="no"><![endif]-->
to your page source? It worked well to work around glitches in IE when a non-classic theme is enabled for me. Note that the conditional comments are there so that firefox does not parse the tag (because it will screw up scrollbars in firefox sometimes).
I just had the same problem with vertical scrollbar in IE7 within the XP theme. After many experiments, I finally found the solution to it. I don't know this solution fits your case.
The container (div#scroll in the example below) with the rendered scrollbars must be larger than 18px. Any number below that will cause the vertical bar disabled.
<div id="scroll">
<div id="fill">
</div>
</div>
The stylesheet, for example:
#fill{
width: 1px;
height: 1000px;
}
#scroll {
width: 18px; /* This has to be larger than or equal to 18. */
height: 50px;
overflow-y: scroll;
}
Thanks,
Grace
In order to avoid certain Windows restrictions, IE re-implements almost all the controls visible on a web page.
The Old New Thing : Windowless controls are not magic
<excerpt>
The Internet Explorer team went and reimplemented all of the controls that a web page would need. They have their own windowless checkbox control, a windowless listbox control,
a windowless edit box, and so on. In addition to reproducing all the functionality of the windowed controls, the Internet Explorer folks also had to reproduce the "look" of the
windowed controls, down to the last pixel. (Functions like
DrawThemeBackground and DrawFrameControl prove extremely helpful here.)
If I recall correctly, the only element that is still windowed is the <SELECT> element.
If you squint, you can see some places where they didn't quite nail it. For example, if you right-click in a text box, options like "Right to left reading order" and "Insert Unicode control character" are missing. As another example, notice that IE's scroll bars do not light up when you hover over them.
</excerpt>
Without seeing the code implementing your page, I would guess that this is another manifestation of "IE's controls don't act native".
If you have a support contract with Microsoft, I'd suggest complaining to them through that channel; if not, see if you get any responses in the microsoft.public.internetexplorer.general newsgroup. Back in IE6, they broke the scrollbar with KB824145 and fixed it with KB832894, so it's not like theses sorts of problems haven't happened and been resolved before.
First, I'll start saying that IE is a terrible browser and in some cases you don't have control over issues while developing a web application.
In that case I haven't encounter such an issue and a Google search don't pull anything on the subject. I'd say it must be something in your code that lead to a weird bug. Most likely it won't break in a lot of systems, so unless it's a very important application (sales, government...) you could leave it that way.
Look at it that way: who change the style of windows to classic? Geeks. And do geeks use IE? No. ^^ ... Joking, but not really.
If it's important I'll need to take a look at your actual code for "The scroll bar has some heavy javascript behind it that drive scrolling of another DIV on the page."