711997 - Pre-render content in animated scale transforms at the higher-resolution endpoint

Status: NEW

(Core :: Layout, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Let's say we're animating a scale transform from scale factors <sx_0, sy_0> to <sx_1, sy_1>.  If we render the frame at <max(sx_0, sx_1), max(sy_0, sy_1)>, then we don't need to redraw it again during the animation, only resample.  This might look strange in the cases where sx_0 < sx_1 and sy_0 > sy_1, or vice versa.  Maybe we want to limit this fast-path to rescales where sx_i == sy_i.

This is intended to be another fast-path alongside bug 702739.

I'm guessing it will be argued that we should rely on the logarithmic repainting instead of adding a special case here.  Perf will be a bit worse in theory, and that approach seems like it will complicate the layers animation setup.  But I guess we'll see.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> This is intended to be another fast-path alongside bug 702739.

Bug 702739 doesn't depend on knowing the end-state of any animation. This does, which would make this harder and a bit more fragile.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> I'm guessing it will be argued that we should rely on the logarithmic
> repainting instead of adding a special case here.  Perf will be a bit worse
> in theory, and that approach seems like it will complicate the layers
> animation setup.

Shouldn't be too bad. Currently we clamp the scale factors to the smallest power of 2 that's greater than or equal to the true scale factor. When animating with OMTC, the true scale factor known to layout will lag behind a bit, so in some cases we might be drawing with a scale factor that's a bit bigger than the clamped-power-of-two scale factor used by layout, so we'll be scaling up a bit instead of scaling down. I don't expect that to be a big deal. We'll have to see.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #1)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> > This is intended to be another fast-path alongside bug 702739.
> 
> Bug 702739 doesn't depend on knowing the end-state of any animation. This
> does, which would make this harder and a bit more fragile.

"fast-path alongside" isn't meant to be particularly deep, but wrt this work, I think of bug 702739 as providing a fast-path for animated translations, as long as the animation code doesn't accidentally invalidate too much.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2)
> When
> animating with OMTC, the true scale factor known to layout will lag behind a
> bit, so in some cases we might be drawing with a scale factor that's a bit
> bigger than the clamped-power-of-two scale factor used by layout, so we'll
> be scaling up a bit instead of scaling down. I don't expect that to be a big
> deal. We'll have to see.

I could imagine things getting a bit tricky if we have to recalibrate the animation if/when layout re-renders.  But maybe we should implement bug 711991 in such a way that that's not a problem ;).  Fwiw, we learned how to do that for the fennec async scale/transform stuff.

There are some cases where I don't expect clamping to behave well, but sure, we'll see.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I wonder if mipmapping from highest resolution is a good compromise, for GPU composited backends.