Last Comment Bug 739176 - No sub-pixel rendering while transitioning translate transforms
: No sub-pixel rendering while transitioning translate transforms
Status: NEW
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 770810
  Show dependency treegraph
 
Reported: 2012-03-26 03:51 PDT by Jake Archibald
Modified: 2015-12-10 10:49 PST (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jake Archibald 2012-03-26 03:51:18 PDT
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11

Steps to reproduce:

http://dabblet.com/gist/2204184


Actual results:

Both circles exhibit a jerky transition on hover


Expected results:

WebKit transitions the 2nd circle using sub-pixel positioning, giving a smoother animation, similar to Flash transitions.

Although this isn't part of the specification, using non-integer pixel values in transforms make animations much smoother, especially on displays where 1 css pixel is greater than one device pixel.
Comment 1 Boris Zbarsky [:bz] 2012-03-26 14:38:23 PDT
As far as I know we do in fact do subpixel positioning for both transforms and style.left....
Comment 2 Jake Archibald 2012-03-26 14:41:33 PDT
It doesn't appear so from the example, or are you seeing something different?
Comment 3 Boris Zbarsky [:bz] 2012-03-26 14:49:37 PDT
I'm definitely seeing the jerkiness in the example; it would be even more obvious if you made the transition 20s long, not 2s long.

What I don't understand is why it's happening; that seems like a paint-time effect, not layout-time...
Comment 4 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-26 15:55:06 PDT
For active transforms, we snap coordinates to integers when rendering. It's a performance improvement because it means we don't need to constantly rerender the transformed object.
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-26 15:56:27 PDT
Note that we snap to device pixels, so for high-density displays it should look smoother.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-26 15:57:39 PDT
We don't currently have support for subpixel rendering of border-radius so even if we did rerender the object on every frame and let its layer take a subpixel offset, the visual results would be the same.
Comment 7 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-26 16:04:04 PDT
I'm not sure what Chrome does ... maybe they render the moving object's layer at a subpixel offset, so it gets resampled? That'd work OK for these green circles, but I think in general it would look poor.
Comment 8 Jake Archibald 2012-03-27 01:45:51 PDT
I'd like to test that assumption, what is 'general' in terms of transitioned & translated items on the web?

Interestingly, Firefox DOES do sub-pixel positioning if you throw in a tiny little rotate http://dabblet.com/gist/2214045. Why switch on this?
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-27 01:50:12 PDT
When we rotate, we have to resample the buffer and things necessarily get blurry.

Try an example that has lots of thin vertical lines that are pixel-aligned, and transition it horizontally, slowly.
Comment 10 Jake Archibald 2012-03-27 01:56:17 PDT
Here you go http://dabblet.com/gist/2214028

I still prefer the 2nd, higher framerate although it phases in and out a bit.

I think you hit the nail on the head when you considered what it might look like 'in general'. I don't think animating things with thin vertical lines is the general case. How would you decide what is general in transitions & transforms?
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-27 02:12:38 PDT
Thanks for that. The text toggling between blurred and non-blurred looks quite awful to me.

It's subjective. We could change our behavior so that your use-cases look better to you, but quite probably someone will soon file a bug complaining that we made their use-cases look worse to them. Unfortunately it's not easy to figure out what maximises the total happiness of users.

The good news is comment #5; as display density increases, this matters less.
Comment 12 Jake Archibald 2012-03-27 02:20:58 PDT
What would convince you that sub pixel positioning would have an overall positive effect? I'm having trouble finding an in-the-wild example that would show the negatives of the slow-moving-text example.

I did a quick poll on Twitter (and I understand this isn't a scientific test) and people were pretty split on the "worst case" example, perhaps even still preferring the webkit method.

Do you have any in-the-wild examples that would be worse off with smoother sub-pixel animation?
Comment 13 Jake Archibald 2012-03-27 02:55:38 PDT
Oops, was supported to link to the tweet https://twitter.com/#!/jaffathecake/status/184564915607056384
Comment 14 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-27 03:08:05 PDT
(In reply to Jake Archibald from comment #12)
> What would convince you that sub pixel positioning would have an overall
> positive effect?

I don't know. Sorry.

> I'm having trouble finding an in-the-wild example that
> would show the negatives of the slow-moving-text example.

Most transitions are not slow enough to show the problem in this bug *or* the text example. As far as I know this is the first Bugzilla bug on the subject.

One extra factor that comes into this is that when not using GPU acceleration, resampling for subpixel offsets is much slower than just copying to integer device coordinates. So we definitely would not change this for the non-accelerated case, and keeping the accelerated case consistent with that is beneficial.
Comment 15 Till Schneidereit [:till] 2013-05-24 15:57:50 PDT
We're running into this while trying to implement Shumway rendering using many DOM elements instead of one large canvas. At least when it comes to Flash animations, there are many cases where this is very clearly visible and looks much worse than what Chrome does.

Is there any chance to get a CSS property similar to `image-rendering` for specifying whether sub-pixel rendering should be applied during transitions or not?
Comment 16 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-05-25 00:30:11 PDT
Can you say something about the content you're animating? And how slow your transitions are?
Comment 17 Till Schneidereit [:till] 2013-05-25 08:44:41 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #16)
> Can you say something about the content you're animating? And how slow your
> transitions are?

As we aren't trying to support some specific content directly, that's hard to do. We want to support as broad a range of existing Flash content as possible.

Supporting very smooth animations even for slow-moving elements is an important quality of the Flash rendering system, however, so not being able to support it would be a serious issue for us.
Comment 18 Till Schneidereit [:till] 2013-06-04 07:45:40 PDT
Apart from Shumway's needs, I think that there are some arguments to be made in favor of always having sub-pixel rendering turned on.

I just stumbled upon a particularly illustrative example of how switching between rendering modes can cause weird effects:

http://jsoverson.github.io/plato/examples/jquery/

Hovering over the graphs will cause info overlays to move around. In those, the text visibly jumps down once the very slight transition applied to the overlay finishes.


Note, though, that I'm still mostly concerned with the needs of the Shumway project, so having a flag that can be set to activate sub-pixel-rendered transitions would work just fine.
Comment 19 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-06-04 19:16:52 PDT
(In reply to Till Schneidereit [:till] from comment #18)
> Hovering over the graphs will cause info overlays to move around. In those,
> the text visibly jumps down once the very slight transition applied to the
> overlay finishes.

I don't see this on Linux, although it may be because Linux doesn't do subpixel text rendering.

I think you can hack around this by adding a very slight rotation to your transform, but there's a performance cost to that especially on non-GPU systems.

I think a reasonable thing to do here would be to enable subpixel rendering for "slow" transitions, e.g. if the difference between one translation and the next is less than 1 pixel in each direction. Would that help your Shumway content?
Comment 20 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-06-17 03:57:14 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #19)
> I think you can hack around this by adding a very slight rotation to your
> transform, but there's a performance cost to that especially on non-GPU
> systems.

Actually you probably can't.
Comment 21 Matty Balaam 2013-09-24 03:54:02 PDT
I have been working on some transforms and noticed they looked awful on Firefox compared to both Chrome and IE 10. 

I have used the rotation hack on the lower example, but subjectively I find Chrome looks much better. 

I have reduced this down, and it can be viewed at: http://codepen.io/MattyBalaam/details/eaJto
Comment 22 Till Schneidereit [:till] 2013-09-24 04:04:03 PDT
Thanks, this is a very nice demo of the problem.

In Chrome Canary, both versions look very smooth, with no internal or external distortions.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #19)
> I think a reasonable thing to do here would be to enable subpixel rendering
> for "slow" transitions, e.g. if the difference between one translation and
> the next is less than 1 pixel in each direction. Would that help your
> Shumway content?

@roc, the problem with this solution is that there'd probably a somewhat visible mode switch between "slow" and "fast" transitions. Except if we interpret "slow" very liberally, of course. In that case, this sounds like a good solution to me.
Comment 23 Till Schneidereit [:till] 2013-11-09 11:25:43 PST
Here's an example I just stumbled upon that suffers very badly from the lack of sub-pixel positioning:
http://www.dragoncastle.eu/

The animation is done by changing the values for top and left, but IIUC, the mechanism for disabling sub-pixel positioning is the same, right?
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-11-12 02:15:47 PST
No. Currently absolute/relative positioning do not trigger layerization. Image rendering snaps to pixels using a different mechanism.

I'm not sure why the text appears to be jiggling up and down in the boxes in Firefox but not in Chrome, but I'm pretty sure it's nothing to do with subpixel positioning or this bug.
Comment 25 Julien Iafrancesco 2013-12-06 01:43:29 PST
I've been struggling with this too. I'm experimenting with the canvas & parallax.js lib and the result is awful in firefox compared to chrome.

Notice pixel snapping when motion comes to an end: http://episode17.com/public/flockr/

For me, rotate(0.0001deg) fixes the problem just fine as any blurring is not really noticeable.
Comment 26 jonathanfever 2015-12-10 10:49:39 PST
I always use a slight rotation of 0.01 and then the element animates smooth without being jerky in Firefox. I add that anytime I animate along the x or y axis.

rotate(0.01deg)

Forking the example from above with slight rotation fix: http://dabblet.com/gist/cde81e39acec41eae786

.test2:hover {
      transform: translate(20px, 0) rotate(0.01deg);
}

Note You need to log in before you can comment on or make changes to this bug.