[Webkit-unassigned] [Bug 81390] New: Reserving textures in the target visibleLayerRect during an animation is not always helpful

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=81390

           Summary: Reserving textures in the target visibleLayerRect
                    during an animation is not always helpful
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: danakj at chromium.org
                CC: jamesr at chromium.org, nduca at chromium.org,
                    vollick at chromium.org, epenner at chromium.org


Copying out context from bug #81106. This is not strictly related to review for that bug so I thought we should not clutter it up.

(In reply to comment #5)
> We do need to start messing around with this, as I suspect we need something along these lines to get good performance. On Android w/ Gmail, Eric reported that we have a substantial hitch at animation start because we do a ton of uploads. There are two reasons:
> 1. The new layer gets put in its final location, so we paint it.

And reserve all the textures in its target visibleLayerRect.

> 2. The layer moving out gets moved offscreen right away, so as I understand it, we promptly discard its textures even though its still onscreen.
>
> I imagine Dana's patch might fix #2 but I assume #1 will still happen.

We will stop culling them via bug #81354. But we won't reserve the textures that are still on the screen since they will fall outside of the target visibleLayerRect.

> It may be we need more-agressive prepainting --- "oh, this layer is offscreen but we'll paint it anyway becausue we have memory to burn." But, this needs the texture manager to come online fully, which is blocked on resolution of the front/backbuffer stuff. Which is not happening fast.

Prepainting is good, but doesn't address reserving the wrong textures due to a visibleLayerRect that is at the layer's target location.

We could say, "Hey, we're moving on the screen..."
1) ...reserve ALL the textures!!  We're likely to hit memory limits, set m_skipsDraw on the layer, and it won't appear on the screen.
2) ...don't reserve any textures and try to prepaint the whole layer.  We rely on prepaint for the whole layer. If we hit a memory limit, we push over what we were able to upload, but the impl thread says "I can't animate with missing textures" and it doesn't display the frame. What we choose to prepaint would determine how this behaved. For example, if we prepainted out from the target visibleLayerRect, it would jump toward the end of the animation if unable to paint everything, and then animate from there?)
3) ...reserve some expanded version of my visibleLayerRect. Double its size in  each direction or something? If the animation isn't enormous we might catch the whole thing with reserved textures, but it's just a guess.
4) ...others?

What do you all think?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.