Bug 82646 – [chromium] Idle painting is not sufficient to pre-paint animated layers and delay animation start time

• Status: RESOLVED
• Resolution: WONTFIX
• Component: CSS

[Eric Penner]

I wanted to see if it was possible to completely pre-paint animated layers, to avoid hiccups due to painting mid-animation. I found that even if I instructed idle-painting to pre-paint all animated layers entirely (basically making https://bugs.webkit.org/show_bug.cgi?id=82117 hyper aggressive), this painting would not occur on the first webkit commit of the animation (which is crucial because it delays animation start times).  However, if I did the painting in the main pass, it would indeed get painted on the first frame and never wait for unpainted tiles.

Maybe there is a way to solve this in the short term to make page transition animations smooth. My first thought is if we had the unclipped visible rect, we could expand it for animated layers until we hit some memory limit (eg. one viewport worth of tiles in addition to the visible part of the layer) and paint it in the main pass rather than the idle pass... Lots of other solutions are possible, like doing two paints in one commit maybe, but I'm less familiar with what we would need for that.

[Dana Jansens]

I think there is a bug wrt animation start times. Vollick just uncovered it today. And it explains the hitching we are seeing when we commit new textures. So I wonder if this is what you are meaning here? I feel like doing a second commit for prepainted textures *should* be enough?

[Eric Penner]

I think it comes down to what we do before we start the animation. If we haven't painted everything before we trigger the animation there will be hitches.

Here's the worst case I can think of with the current setup: 

- You have a new layer that is partially visible and is about to be uncovered by an animation that takes 0.2 seconds. 

- The layer paints some small piece of itself during the first commit in the main pass. Idle-painting gets pre-empted and doesn't run on that commit. 

- The animation starts and is immediately blocked by the remaining unpainted tiles. 

- The next commit paints most of the new viewport worth of tiles, taking greater than .2 seconds to complete, resulting in jumping immediately to the end of the animation.

[Dana Jansens]

You're right, this can happen.

Here's what Ian realized today though. We currently wait for the animation to start on the impl thread but this is wrong. It needs to start exactly at the time when WebKit gives it to us so it is in sync with WebKit.

This means if we make a very slow paint and then commit it, we'll miss the animation anyways.

I think in general, prepainting should be enough in the second commit. Even when we don't prepaint and a tile comes on screen, about:tracing seemed to say we were easily able to paint it before the next frame.

We are seeing a lot of bad effects around this use case because of the hitching in the times, and this is because we are starting the animation late on the impl thread.. if Ian's observations today hold up to the 24 hour test :)

Either way, I expect that this will become a non-issue once he fixes the synchronization issues we're seeing when main thread commits. And if it's the way I think we'll fix it, then we will be far better off starting the animation as fast as possible and prepainting non-visible stuff to try catch up after the first commit.

[Eric Penner]

> 
> Either way, I expect that this will become a non-issue once he fixes the synchronization issues we're seeing when main thread commits. And if it's the way I think we'll fix it, then we will be far better off starting the animation as fast as possible and prepainting non-visible stuff to try catch up after the first commit.

Sounds like a great find! 

I'm pretty convinced this is still an issue based on the early experiment I did, but we can see how things pan out. As an example to illustrate why I'm still convinced we need to do some work upfront: I've seen some transitions where the work required (painting and uploads), takes 1.5x the length of the subsequent animation. I'll dig up a trace to illustrate further.

[Dana Jansens]

(In reply to comment #4)
> > 
> > Either way, I expect that this will become a non-issue once he fixes the synchronization issues we're seeing when main thread commits. And if it's the way I think we'll fix it, then we will be far better off starting the animation as fast as possible and prepainting non-visible stuff to try catch up after the first commit.
> 
> Sounds like a great find! 
> 
> I'm pretty convinced this is still an issue based on the early experiment I did, but we can see how things pan out. As an example to illustrate why I'm still convinced we need to do some work upfront: I've seen some transitions where the work required (painting and uploads), takes 1.5x the length of the subsequent animation. I'll dig up a trace to illustrate further.

Hm, yes please!

I wonder what would happen if we didn't accelerate these animations. On the software path would they just not happen and the element jump to its destination?

[Eric Penner]

(In reply to comment #5)
> (In reply to comment #4)
> > > 
> > > Either way, I expect that this will become a non-issue once he fixes the synchronization issues we're seeing when main thread commits. And if it's the way I think we'll fix it, then we will be far better off starting the animation as fast as possible and prepainting non-visible stuff to try catch up after the first commit.
> > 
> > Sounds like a great find! 
> > 
> > I'm pretty convinced this is still an issue based on the early experiment I did, but we can see how things pan out. As an example to illustrate why I'm still convinced we need to do some work upfront: I've seen some transitions where the work required (painting and uploads), takes 1.5x the length of the subsequent animation. I'll dig up a trace to illustrate further.
> 
> Hm, yes please!
> 
> I wonder what would happen if we didn't accelerate these animations. On the software path would they just not happen and the element jump to its destination?

Yes. But that's not to say it has to. Even the not threaded path could run faster if we did more work upfront.

[Dana Jansens]

This is obsolete by impl side painting right? Closing.