I suspect this has to do with some bugs in the browser, involving opacity, transitions and translations.
I wasn't able to reproduce the glitch in a code snippet, so I'll have to point you to the live site:
tzork.com
My full source code is here: MightyPork/tzork, including the SCSS and Typescript that's compiled to CSS and JS. If you have time and can reproduce the bug, I'd be most grateful if you tried to find what's wrong. I've never seen anything quite like this before.
When you put mouse over the labels, they get a background and a border on one side, which should be 2px wide. Sometimes though, Chrome shows just one pixel. When I change the width to 1px, sometimes it shows no border at all (only near the corners).
You can clearly see how inconsistent it gets. My browser zoom is at 100%, so that is not the cause.
I'm not sure what's up, but it apparently depends on the current time = angle = position of the labels, and WINDOW SIZE.
I round the position to nearest pixel, so fractional position is not the cause.
I also tried rounding to odd / even pixel, that but didn't help either.
Another issue is that in Firefox, sometimes hovering the labels causes numbers on the clock face to move / change letter spacing. I don't get it, there's no connection at all.
In chrome sometimes there appear weird tiling glitch on the background image (notably when the dev tools panel is open).
Ok, so the solution:
I added this all over the place, and the render glitches have disappeared.
-webkit-transform: translate3d(0,0,0);
I don't get it.
Related
The background:
I am making a 2D HTML/CSS animation using JQuery. This will place roughly 25 same-sized images on top of each other, moving some as desired. UI elements get a pixel position and are much smaller than the full-sized images. I have recently moved from forcing hardware acceleration form backface-visibility: hidden to will-change css properties. The entire animation is scaled by the div it is contained in and the css transform property.
The problem:
In Google Chrome specifically, the compositing starts malfunctioning in certain scenes, in a reproduceable but seemingly random manner. Images are partly cut off, images are placed behind images they are supposed to be on top of, the like. Scrolling up and down replaces some malfunctions with others, as does changing the display properties of some items (happens due to UI interaction).
The question:
What is causing this behaviour, why are all my other test browsers (firefox, opera, internet explorer, edge) not affected, and how can I avoid it?
My current status:
From what I have tried so far and my gut feeling this is an issue caused by overuse of hardware acceleration or the transform: scale css property, or a combination of both. I'm currently working on other scaling methods as the easiest "fix" to the problem, but I still do not know what is causing all of this. Sadly all of my UI elements aren't a neat % of the parent.
What I tried:
Firstly I tried setting the z-index for all elements manually. This accomplished nothing, sadly.
As sometimes scrolling up/down or interacting with the UI seemed to fix problems, I tried adding a method that would force the browser to re-do the layout at certain points in code. This argueably only made things worse, as it added a lot of white flickering, and failed to fix the issue.
I tried switching animation libraries from jquery to velocity, which did not help.
I removed the "hack" that forced things into hardware acceleration. This fixed the compositing problem, but reintroduced choppy animations in chrome (only).
I then tried to assign hardware acceleration on a need-to-get basis by adding and removing a css class containing the "hack". The behaviour was the same as in 4 .
I tried using will-change instead of the backface visibility hack, but this just set the behaviour back to where it was before I started my attempts at fixing this.
I tried reducing the amount of layers while keeping hardware acceleration. I used jquerys ".hide()" on elements only animating once replaced the final picture with a singular image. This did not fix the issue of composite "mashup".
Finally, I disabled the css transform scale property, which fixed the unexpected behaviour, but is imperative so I can scale my animation for screen size.
Some code:
Here's some css code of the animation container
.animationContainer {
position: relative;
width:2560px;
height:1440px;
/*transform: scale(0.55);*/
transform-origin: top left;
overflow: hidden;
display: inline-block;
}
And some javascript detailing the animation I use for the majority of objects, making them "fall" into the scene
function fadein(el, direct)
{
var falldistance = 150;
$(el).show();
$(el).css("opacity", 0.0);
switch(direct) {
case 0:
$(el).css("top", "-="+falldistance);
$(el).animate(
{
top: "+="+falldistance,
opacity: 1.0
}, 1000);
break;
[...]
I do not know how useful more code would be, if you require any more please ask. Web design isn't a field I have much experience in, and I am slowly running out of ideas. Any help or suggestions would be appreciated.
Example Visual:
This is an example of one of the bugs:
This is what it looks like after scrolling down and back up in the browser:
I'm a little bit stuck here..
This is the page I'm working on:
The issue I'm having is that the images in the 'In der Nähe'-box on the right seam to have a blur effect on them. And I can't figure out where that is coming from.
I suspect CSS, or JS since when opening the images in a new tab, they show as bright as they are:
Usually Firebug, or Chrome Dev Tools help me finding the origin of such issues, but in this case I can't find any opacity or filter attribute in there.
What am I missing? What other ways are there to give a blur effect to an image?
There's an opacity: 0.7 rule on the entire div; the one of class notes.
As Lightness Races in Orbit (what a mouthful!) points out, there an opacity: 0.7 on the class .notes BUT that is not everything. All those images are upscaled. I.e. there actual size is smaller than the rendered size. This may cause the image to be less sharp than it should.
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I have a simple table with css. When I add a bottom border to the middle row, the next row has a really weird border. it happens only in chrome, and I have no idea why.
I should say the I apply the bottom border to the middle row using javascript (because I don't know the size of the table beforehand). I tried to apply without javascript, and it works without the weird problem.
here is an example of the table, notice the borders in the middle:
http://ri-cloud.appspot.com/super_tacticko?create
here is the javascipt I'm using to create the middle line:
// add the middle line
var half = height / 2; // it has to be zugi anyway
var $middle = $('tr').slice(half-1, half);
$middle.find('td').addClass('middle-td');
If resizing the window fixes the issue (as it does in my case also) it is most likely a rendering bug... Chrome has a number of these that spring up from time to time, mainly because it tries to be faster than everything else by cutting corners (imo).
The only way to work around a bug is to keep trying different approaches until you find one that doesn't trigger the issue, either that or try programatically resizing your table/body after it's been created and then put it back to the right size again — this may force Chrome to redraw correctly... and should occur quickly enough that the users wont notice. A third approach could be to build the table entirely in JavaScript and once properly formed, embed it into the page.
The reason why the CSS method probably works is because it will be using Chrome's rendering methods at a different point in the rendering process to that of the JavaScript style modifications.
Basically, I have seen Chrome do some pretty strange things. The hacks I've used in the past to get around odd Chrome problems have been:
Use decimals in dimension calculations — i.e. 30.1px instead of 30px
Not setting opacity to full — i.e. 0.99 instead of 1.0
Not to use an ip address prefixed with a . when setting a cookie
Use overflow: hidden to repair strange renderings in certain situations.
Oh just for the record I'm viewing on Windows 7 via Chrome v25.0.1364.97
I have run into similar problems in Chrome on Windows 10. The cause of this problem is that Chrome is not working correctly with Windows text-size settings feature (IMHO changing DPI in Win OS). When I have switched from 125% text size to 100% text size, Chrome was rendering my HTML table correctly. As far as I have been testing, other browsers are working with this feature OK.
Finally I made a quick fix to this issue as follows:
table {
tr td {
border-color: transparent !important;
outline: 1px solid #666;
}
}
It is not bullet-proof, the sizes of borders are 2px, but better something than nothing.
So a fellow StackOverflow-er wrote out some jQuery based Javascript for me a few days ago.
It works, but there's an annoying issue with it and I wondered if anyone could help out.
The JavaScript is calculating a margin for alignment purposes. The value it calculates is is not always an exact pixel, e.g sometimes its 14.4 etc. In Firefox the issue does not exist, but in other browsers such as in Safari or Chrome when the margin is being calculated (as the screen is re-sized) the far right hand side box 'jumps' and never quite stays against the edge of the container.
As I said above, in Firefox it does not 'jump', and this is the effect I was looking for.
Is there anything that could be done to stop this 'jumping' effect or is it completely related to the browsers rendering engine and out of my control? :(
This JSFiddle contains the code/demo : http://jsfiddle.net/m4rGp/1/
(Try resizing the browser width in Firefox then Safari/Chrome and you will notice the jump on the right)
Any reply's are really, really appreciated! Many thanks
This is because of the rendering engine only. There are no decimals in pixel. 1px is the smallest addressable screen element. So before changing the margin add a Math.round
$(".barModules li").css('margin-left', Math.round(dynMargin) + "px");
yet the bouncing will be there because the element is positioned in such a way that it is bound to its left (reference). When it sees the attribute margin-right:0, it tries to activate that one too ... but due to its margin-left being set and positioning based on left .... it is bouncing like that. like a debounced function call.
If your aim is to get a dynamic margin, then you have to adjust with this, else go for a fixed width page with centered elements and you don't have to worry about overflow problem