Open Bug 757870 Opened 13 years ago Updated 2 years ago

jittery behavior when scale/translating elements using CSS transform

Categories

(Core :: Web Painting, defect)

defect

Tracking

()

People

(Reporter: getify, Unassigned)

References

()

Details

(Whiteboard: DUPEME)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120522 Firefox/14.0a2 Build ID: 20120522042008 Steps to reproduce: I have images that are places inside parent divs (aka, "tiles"), and then i have a "zoom" feature that is accomplished by applying CSS transform (scale/translate) to the tiles so that they get bigger/smaller as you zoom in/out respectively. Inside each parent tile div, the images themselves are actually positioned using CSS translate instead of left/top positioning. All images are absolutely positioned at 0,0, and all tiles are also absolutely positioned at 0,0, and the positioning is entirely taken care of by translate. Actual results: In Chrome 21, this works just fine. In FF14, there appears to be some jittery behavior where once a change is applied to the tiles to scale/translate them to a different "zoom" level, the images in those tiles are "approximated" to a close location (slightly blurry even), and then a half-second later, they're repainted to a more accurate location. this repaint would be fine if the image was going from blurry to clear only, but the jittery repositioning of it is intolerable. BTW, in the video, you see that these zoom in/out movements are smoothed out using a CSS transition. Even if I take out the transition, the jittery behavior still occurs in FF, so it's not related to that. Here is a screencast showing the behavior: http://www.screenr.com/N1X8 I have a theory that perhaps this has something to do with sub-pixel rendering or something like that? The zoom in/out scaling and repositioning definitely leads to non-whole numbers being applied to the CSS values, like a scale of 0.66666666667 and a translate of (123.5px, 300.03333333px), etc. I am also applying translateZ(0px) to all these CSS transform'd elements, which is hopefully allowing these renderings to be hardware accelerated. Expected results: I expect that FF14 should handle CSS scale/translate much the same as CH21 in terms of smoothness of rendering (without the jittery behavior).
BTW, I do *not* see any jittery behavior when I am only translating the tiles around with scale(1,1). It's seems only to be when scale is applied to "zoom in" or "zoom out" that this jittery behavior kicks in.
Can you provide the testcase either as URL or as attachment ?
(In reply to Matthias Versen (Matti) from comment #2) > Can you provide the testcase either as URL or as attachment ? http://test.getify.com/firefox-bug757870.html
BTW, here's a video capturing the jittering (especially towards the end of the video) after scaling changes. http://www.screenr.com/RKX8
Just tried this on a different windows 7 computer, which has FF12... got same jittering. Have heard reports that FF12 on macOS doesn't have the jittering, so perhaps this is windows only bug?
I can confirm the issue with Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1 The component is only a guess....
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Product: Firefox → Core
QA Contact: untriaged → layout
Version: 14 Branch → Trunk
Component: Layout → Layout: View Rendering
QA Contact: layout → layout.view-rendering
Whiteboard: DUPEME
BTW, it's happening on mac and windows.. currently using FF18 and it's still doing it. In fact, it used to not happen on Chrome, and I recently noticed that Chrome suffers it now too.
Bump. Just re-tested in FF23 and it's still adjustment-jittering (minor, but noticeable if you look closely) after the transform, regardless of animation or not.
OS: Windows 7 → All
Hardware: x86 → All
Possibly related: bug 1024152 and bug 860261. Also visible in attachment 8550808 [details] (testcase for bug 1122885).
Still seeing this in 54 (64-bit) on Win10.
Component: Layout: View Rendering → Layout: Web Painting
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.