while drawing animation, why should call parent.invalidate(true)

183 views
Skip to first unread message

shench...@gmail.com

unread,
Aug 6, 2013, 11:19:44 PM8/6/13
to android-...@googlegroups.com
Hello, all

When a view has a animation and is drawing it, I found the dirty region size to be redrawn is its parents' size, not its own size, the dirty region is too large, so the device will cost too much comsumption while drawing animation.

I checked the code(Android 4.2), I found the dirty region is its parents' size becase of the below code in View.java

    boolean draw(Canvas canvas, ViewGroup parent, long drawingTime) {
        ...
        if (more && hardwareAccelerated) {
            // invalidation is the trigger to recreate display lists, so if we're using
            // display lists to render, force an invalidate to allow the animation to
            // continue drawing another frame
            parent.invalidate(true);
            if (a.hasAlpha() && (mPrivateFlags & PFLAG_ALPHA_SET) == PFLAG_ALPHA_SET) {
                // alpha animations should cause the child to recreate its display list
                invalidate(true);
            }
        }
        ...
    }

I deleted parent.invalidate(true) and tested animation again, I found everything is ok, drawing animation is ok, dirty region is small, comsumption is low.

So I have several questions.

#1 why should call parent.invalidate(true), because in View.drawAnimation, it has already called parent.invalidate(mLeft, mTop, mRight, mBottom) or parent.invalidate(left, top, left + (int) (region.width() + .5f),top + (int) (region.height() + .5f)), so called parent.invalidate(true) again seemed meaningless.

#2 If parent.invalidate(true) is really need to be called, what type of animation will behaviour badly if I deleted parent.invalidate(true)

Thanks and applogize for my poor English.

ch...@android.com

unread,
Aug 7, 2013, 6:20:55 PM8/7/13
to android-...@googlegroups.com
Hi,

Thanks for the report.
That final invalidate() does seem incorrect; the initial invalidates based on the actual area of the child should take care of invalidating the correct area.
However, the code around there hasn't changed in a while, so it's entirely possible that the current code is masking some issue with not invalidating enough, so I'd be afraid to simply remove the final invalidate() and discover new artifacts from not invalidating enough.
I'll file a bug internally and test some cases to see what we can safely remove.

Chet.
Reply all
Reply to author
Forward
0 new messages