Open Bug 711997 Opened 10 years ago Updated 8 years ago

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

Categories

(Core :: Layout, defect)

x86
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: cjones, Unassigned)

References

Details

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.
(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.
(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.
(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.
Blocks: 706179
I wonder if mipmapping from highest resolution is a good compromise, for GPU composited backends.
You need to log in before you can comment on or make changes to this bug.