Issue 704256  has been merged into this issue.

To clarify, is this a Shaka Player bug that we should be updating the page differently?  Or a bug in the way Chromium calculates the damage rect for our demo?

I think some of both. Shaka player shouldn't need to update the css so often, and chrome shouldn't need to have the damage rect as big as it is.

Understood.  Could you please file a bug to that effect on our issue tracker?  https://github.com/google/shaka-player/issues  We don't typically use crbug for Shaka Player.

The problem is most likely due to CSS transitioning the opacity because I only see repaints outside the video area when the mouse moves in and out of the video area.

There is no spurious invalidation when the mouse is motionless outside the video. The large area invalidation appears to be associated with the mouse entering and leaving the video area, so probably has to do with the opacity change happening - that can result in major changes to the layerization of the page, and lots of repaint.

I think the Shaka player should sort out its updating of non-visible elements (opacity 0 on the container) before we try to fix the issue, as the two are undoubtedly related. I'm marking it WontFix for now, as it is a website issue at this stage.

This does not need a bisect.

Please file a bug on Shaka Player with your request: https://github.com/google/shaka-player/issues/new

schenney, are you saying that the damage I see in the attached image (happens in about 1 in 5 frames, even when not moving the mouse at all) isn't caused by some input from blink, but is instead from cc?

Deleted: shakadamage.png 221 KB

	shakadamage.png 221 KB View Download

Sorry, I didn't mean to say that Blink is not issuing the repaint. A damage rect like that is most likely caused by a DOM element changing, and that DOM element is both not visible for some reason and is off the left or otherwise covers a large width of screen. Just because you can't see it doesn't mean there isn't some element there that is changing such that we think it might need repainting.

Invalidation is conservative. We can't know for sure what visible effect a change might have until we actually fill pixels, so we need to issue invalidation for all of the element's bounds, and maybe its ancestors or descendants too.

Reported https://github.com/google/shaka-player/issues/749

Wonderful, thanks!

Assigning back to jbauman for whatever Chrome work may be deemed necessary.  We should be able to quiet down the video controls on our side.

Currently fixed, at least in the nightly build of shaka player.