Webkit的动画留下垃圾像素背后的屏幕上 [英] Webkit animation is leaving junk pixels behind on the screen
问题描述
以下code使屏幕上的一个白框。如果您在iPad上运行这个（你可以调整的像素以在iPhone上运行它，太），当你触摸框，它会飞奔关闭屏幕，并留下沿其底边白十岁上下的像素的痕迹。
＆LT;！DOCTYPE HTML＆GT;
＆LT; HTML和GT;
＆LT; HEAD＆GT;
＆LT; META HTTP-EQUIV =内容类型内容=text / html的;字符集= UTF-8/＆GT;
＆LT; META NAME =视口CONTENT =WIDTH =设备的高度，用户可扩展性=无，最大规模= 1，最低规模= 1/＆GT;
＆LT;标题＆GT;线路错误演示＆LT; /标题＆GT;
＆LT;风格＆GT;
身体 {
背景：黑色;
}
.panel {
背景：白色;
位置：绝对的;
的z-index：2;
宽度：1000像素;
高度：500像素;
顶部：34像素;
左：12px的;
-webkit-边界半径：20像素;
-webkit-过渡：左0.333s易于在出;
}
.panel.hide {
左：-1000px;
}
＆LT; /风格＆GT;
＆LT; /头＆GT;
＆LT;身体GT;
＆LT; DIV CLASS =面板的onclick =this.setAttribute（类，面板隐藏'）＆GT;＆LT; / DIV＆GT;
＆LT; /身体GT;
＆LT; / HTML＆GT;
敲门砖错误使用边框半径，做动画。如果你只是弹出它关闭屏幕，没有任何线索。如果没有边框半径，无痕迹。
下面是到目前为止，我已经找到了变通：
.panel.hide {-webkit-边界半径：0; }
丑，而不是为我的应用程序真正实用的，因为我在动画面板和出两者，我真正想要的圆角当它在屏幕上。
另：
.panel {-webkit-变换：translateZ（0）; }
这使面板到硬件管道，这不正确的合成。虽然这适用于这个简单的演示，用我的真正的web应用程序的硬件管道导致了内存不足的错误。 （的激烈，巨大的，直接的品种）。
我怎么可能摆脱这条古道的任何其他的想法？
将溶液
的box-shadow：0 0 1px的RGBA（0，0，0，0.05）。
如果你觉得这是太明显，您可以使用您的盒子作为的box-shadow 颜色的背景颜色。
可替换地，根据本<一href=\"http://stackoverflow.com/questions/12348884/jquery-ui-draggable-element-leaves-weird-traces-in-chrome/12352196#12352196\">answer在Chrome浏览器类似的问题（感谢在尖断的意见塞巴斯蒂安），你可以想尝试：
概述：1px的透明固体;
这是怎么回事？
我给了一个<一个href=\"http://stackoverflow.com/questions/17575624/how-can-i-avoid-animation-artifacts-on-my-touch-draggable-border-radius-element/17723401#17723401\">fairly冗长的解释的其他地方，但这里的短版。出于性能的考虑，只的WebKit重新绘制它认为可能已经改变页面的一部分。然而，iOS的（pre-7）的Safari执行边界半径的抗别名超出盒的所计算尺寸的几个像素。由于WebKit的不知道这些像素，他们没有得到重绘;相反，他们留下，并建立每个动画帧。
通常的解决办法，我在其他建议的回答，很给力的元素，需要硬件加速，使其被描绘成一个单独的层。然而，太多的小分子或几个大的会导致大量的瓷砖越来越推到了GPU，具有明显的性能影响。
使用的box-shadow 更直接地解决了这个问题：它扩展盒的尺寸重绘，迫使WebKit的重新绘制额外的像素。在移动浏览器的box-shadow 的已知的性能影响都直接关系到使用的模糊半径，所以一个像素的阴影应该有小到没有影响。
The following code puts a white box on the screen. If you run this on an iPad (you can adjust the pixels to run it on an iPhone, too), when you touch the box, it will scoot off the screen, and leave a trail of white-ish pixels along its bottom edge.
<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-height, user-scalable=no, maximum-scale=1, minimum-scale=1" />
<title>Line Bug Demo</title>
<style>
body {
background: black;
}
.panel {
background: white;
position: absolute;
z-index: 2;
width: 1000px;
height: 500px;
top: 34px;
left: 12px;
-webkit-border-radius: 20px;
-webkit-transition: left 0.333s ease-in-out;
}
.panel.hide {
left: -1000px;
}
</style>
</head>
<body>
<div class="panel" onclick="this.setAttribute('class', 'panel hide')"></div>
</body>
</html>
The key to getting the bug is using a border radius, and doing animation. If you just pop it off the screen, no trail. If there is no border radius, no trail.
Here are the work-arounds I've found so far:
.panel.hide { -webkit-border-radius: 0; }
Ugly, and not really practical for my application, because I'm animating the panel both in and out, and I really want the rounded corners when it is on screen.
Another:
.panel { -webkit-transform: translateZ(0); }
That puts the panel into the hardware pipeline, which does the compositing correctly. Although this works with this simple demo, using the hardware pipeline in my real web app causes out-of-memory errors. (Of the drastic, huge, immediate variety.)
Any other ideas of how I might get rid of this trail?
The solution
box-shadow: 0 0 1px rgba(0, 0, 0, 0.05);
You can use the background colour of your box as the box-shadow colour if you feel this is too noticeable.
Alternatively, according to this answer on a similar issue in Chrome (thanks to Sebastian in the comments for the tip-off), you may want to try:
outline: 1px solid transparent;
What's going on?
I've given a fairly lengthy explanation elsewhere, but here's the short version. For performance reasons, WebKit only repaints those part of a page that it thinks might have changed. However, the iOS (pre-7) Safari implementation of border radius anti-aliases a few pixels beyond the calculated dimensions of a box. Since WebKit doesn't know about these pixels, they don't get redrawn; instead, they are left behind and build up on each animation frame.
The usual solution—as I suggested in my other answer—is to force that element to require hardware acceleration so that it gets painted as a separate layer. However, too many small elements or a few large ones will result in a lot of tiles getting pushed to the GPU, with obvious performance implications.
Using box-shadow solves the problem more directly: it extends the repaint dimensions of the box, forcing WebKit to repaint the extra pixels. The known performance implications of box-shadow in mobile browsers are directly related to the blur radius used, so a one pixel shadow should have little-to-no effect.
这篇关于Webkit的动画留下垃圾像素背后的屏幕上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
