How can I avoid animation artifacts on my touch-draggable border-radius element on iPad?
The fix
Add this rule to your #bawl { … }
ruleset:
-webkit-transform: translateZ(0);
(If you need to avoid hardware acceleration, you can use outline: 1px solid transparent
—for more details, see my answer to a similar question.)
This removes the trailing artefacts, but why? It's a combination of Quartz (the drawing engine in iOS) not clipping anti-aliased lines to the edges of a shape and how WebKit repaints a web page after part of it changes.
Drawing a webpage
First, a quick and (over)simplified run down of how WebKit gets from a tree of DOM nodes to a bitmap image representing the rendered webpage.
You already know that a webpage gets parsed into a tree of elements, called the DOM. Each node in the DOM is presented in a certain way depending on the styles applied to it. It is possible for nodes to overlap, or be overlapped by, other nodes depending on things like z-order, transparency, overflow, positioning etc.
This is broadly similar to how things work under the hood. WebKit maps each DOM node to a corresponding RenderObject
, which has all the information it needs to paint an individual DOM node. Each RenderObject
is mapped to either its own or an ancestor's RenderLayer
, which is a conceptual way of dealing with how nodes are "layered"—i.e. painted over or under other nodes.
To render a webpage, each RenderLayer
is painted from back-to-front by z-order. Children behind that layer painted are first, followed by the layer itself, followed by children in front of it. To paint itself, the RenderLayer
calls the paint method on its corresponding RenderObject
s.
WebKit has two code paths for rendering a given RenderLayer
: the software path and the hardware accelerated path. The software path paints each RenderObject
directly to the image of the rendered webpage that you see in your browser, whereas the hardware path allows certain RenderLayer
s to be designated as compositing layers, which means that it and its children are drawn separately and finally composited into a single image by the GPU. The hardware path is used whenever one or more of the RenderLayer
s on a page require hardware acceleration, or when it is explicitly required by a flag in the browser (e.g. Chrome).
Updating part of a webpage
When an animation or some other event changes how part of a page looks, you don't want to redraw the entire webpage. Instead, WebKit draws a box around the changed area—the damage rect—and only redraws bits of each RenderLayer
that overlap with that box. A RenderLayer
that doesn't overlap the damage rect is skipped entirely.
If you're rendering via the software path, WebKit directly recomposes the damage rect onto the bitmap image of the full rendered page, leaving the rest of the image unchanged. The hardware path, however, repaints each compositing layer separately and recomposites them into a new image.
What is going wrong
The translateZ
fix applies a 3D transform to the element. This forces the RenderLayer
that paints the ball to require hardware acceleration, meaning that WebKit will use the hardware path instead of the software path. This implies that the problem is related to using the software path.
When the ball is painted, the border radius means that the edges are anti-aliased. Because of a known issue related to Quartz, the edges of the shape are anti-aliased such that some pixels fall outside of the damage rect calculated when you change the ball's position on the page. Using the software path, the browser redraws only the changed region of the rendered page image, leaving the rest of the image untouched. The semi-transparent pixels that fall outside of this area won't be updated, which accounts for the artefacts left behind when you move the ball.
By contrast, the hardware path redraws that layer (and its child layers) separately then recomposites the page. No "ghost pixels" are left over from the last time that layer was rendered.
TL;DR
When WebKit uses the software rendering path, changes to part of a page are made directly to the image representing the whole page. For performance reasons, WebKit only redraws those parts of an image that have changed. However, when Quartz draws a rounded rectangle, it anti-aliases the edges such that some pixels fall outside the region that WebKit knows to redraw. The fix is to force that layer to require hardware acceleration by applying a 3D transform, meaning that element is drawn separately from the rest of the page and recomposed after.
Webkit animation is leaving junk pixels behind on the screen
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.
Safari on IOS window dragging and styling problem
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
There ya go! You're going to have to make your design work at that zoom though. Also playing with scales gives different results. Good luck with iOS web design!
CSS Animation leaves stray pixels behind
It seems to me that the letter-spacing
property on the anchor
tags is causing some kind of calculation error for the rendering engine which causes it to leave a stray pixel.
So there are two solutions I was able to come up with:
Solution 1:
Use transform to do it like so:
.nav-bar-flex > a::after {
content: "";
display: block;
width: 100%;
border-bottom: 2px var(--secondary-orange) solid;
margin-top: 0.3rem;
transition: transform 300ms;
transform: scaleX(0);
transform-origin: left;
}
.nav-bar-flex > a:hover::after {
transform: scaleX(1);
}
Solution 2:
Remove letter-spacing
from the anchor
tags.
By the way, since you have transition on the actual element you do not need to have it again on the hover event.
Convert existing html.erb to Haml
There you go: http://html2haml.heroku.com/
EDIT: Moved to https://html2haml.herokuapp.com/
Related Topics
How to Add a Drop Shadow to Chart.Js Line Chart
Show One Bootstrap Carousel Item in Mobile
-Webkit-Tap-Highlight-Color: Rgba(0,0,0,0); on a Div
Alter CSS Class Attributes with JavaScript
How to Change Tooltip Text for Google Chart API
Columns of Equal Height with Jquery
How to Convert Rgba to Hex Color Code Using JavaScript
Fastest Selector Method in Jquery and CSS - Id or Not
Changing CSS Variables via Js in Polymer
Bootstrap Dropdown in Collapse Not Showing on First Attempt
Fullcalendar.Io: How to Display One Event Per Line in Agendaweek Then Mix All in One
How to Put Logical Operators in Document.Queryselectorall? If So, How
Parse CSS Gradient Rule with JavaScript Regex
Jquery + Animate.CSS Animation Only Working Once, Animation Not Resetting
Toggle Sidebar Div with Another Div Using CSS/Javascript
Fixed/Absolute Positioning Neglected in iOS When Focusing on Input