I could repro this bug ONLY in RDP session. The frame refreshing becomes very slow in fullscreen mode, I can see obvious glitch in frame refreshing. This doesn't seems a recent regression, it repro on Chrome 63 as well.
dale, can you assign appropriately?

this may be a duplicate of 772761?

I'm able to repro this on ChromeOS 65.0.3319.0, with YouTube.

1. Navigate to a YouTube video page (e.g. this trailer https://www.youtube.com/watch?v=6ZfuNTqbHE8).
2. Start playing the video.
3. Click to full-screen it.

At #3 the video will play normally, and full-screen, for a second or so, after which it will only update the top-level portion of the video.

If you move the mouse while the video is playing in the top-left corner then the entire frame is rendered.

Turns out that this is actually a scaling rather than a full-screen issue. :)

Putting this here, since description editing seems to be broken.

Chrome Version: 65.0.3312.1
OS: Windows 10, ChromeOS

What steps will reproduce the problem?
(1) Navigate to a video in YouTube (e.g. I picked the next Avengers movie trailer).
(2) Using the cog icon, choose a video resolution that is smaller than the playback area.
- If playing full-screen on a 1080p or larger display, you might choose 480p or 720p.
- If playing back in a tab, setting 240p will usually show the problem.
(3) Play the video.

What is the expected result?

Expect that the entire video area is updated.

What happens instead?

Only the top-left portion of the video is updated, most of the time. The portion updated corresponds to the actual size of the source video, as though the scaled-up output is being clipped to that.  However, if you move the mouse then the video will update normally.  It seems that we're not correctly scaling-up the "dirty region" we're reporting to the compositor on each frame.

You can repro the same effect by the following:
1. Find a device that supports hi-DPI (i.e. more than one physical pixel for each logical pixel, e.g Chromebook Pixel, or newer Windows laptops). I used a Windows laptop configured for 1.5x desktop scaling (i.e. 1.5 physical pixels for each logical pixel, in both dimensions).
2. Configure the video for the same logical dimensions as the playback area.
3. Play the video.

In this case only the top-left corner of the video will update, similarly to the low-res playback repro steps, above.

that's interesting.  i wonder if the damage calculation in viz is ignoring the "stretch content to fill bounds" flag on the quad when a new frame arrives for the surface.

i suspect that it's not damage from the layer tree side, since the (surface) layer is the correct scaled size.  otherwise, it'd never be drawn properly.

For these kinds of bugs, you need to be on a platform that supports partial swap (e.g. windows, chromeos), as that's what the damage eventually routes to.  You might be able to repro with --force-device-scale-factor=2 even on a lodpi monitor.

Is there a mismatch between surface size and coded size?
 https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/VideoFrameSubmitter.cpp?sq=package:chromium&dr=CSs&l=115

The damage rect there on the render pass is supposed to be the size in physical pixels.

re c#10, i'm not sure that i get it.  here's my rather limited understanding.

the output and damage rects on the CompositorFrame from VideoFrameSubmitter are the same as the surface size - we set them all in that function to the video frame's coded_size().  so the entire surface should be marked as damaged when a new CompositorFrame arrives, shouldn't it?

i'm not sure why it matters if the coded size is the wrong size, as long as we use the same size in all three places.  shouldn't any stretch-to-full SurfaceDrawQuad that refers to that surface be completely redrawn, regardless of the SurfaceDrawQuad's physical size, when a new frame arrives?

or, to put it another way, how would anything (e.g., VideoFrameSubmitter) that's pushing frames to the frame sink know (or care, really) how many physical pixels are covered by the SurfaceDrawQuad(s!) that's using it?

ah, this stuff confuses me.  :)

I think it could be relative to the device scale on the surface itself (which usually is part of the conversion to physical pixels).  I am not quite sure what the problem is here, but investigating values of damage, sizes, scales, final sizes, etc, should help indicate what the issue is.

 Issue 804693  has been merged into this issue.

Seems similar to https://bugs.chromium.org/p/chromium/issues/detail?id=737255. Still trying to see what value need to updated. 

Issue 807220 has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ef34f452a768d96ecf337cdaa45b795d190ecda

commit 7ef34f452a768d96ecf337cdaa45b795d190ecda
Author: CJ Dimeglio <lethalantidote@chromium.org>
Date: Fri Feb 02 02:09:52 2018

Adds stretch_to_fit support for surface aggregation.

This CL makes it so that if |stretch_to_fit_bounds| is set on a surface,
damage calculation takes this into account and scales the damage quad
accordingly.

Bug:  799512 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I405ae815046d7ab51179bfceb0e54db9e5749725
Reviewed-on: https://chromium-review.googlesource.com/887789
Commit-Queue: CJ DiMeglio <lethalantidote@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533915}
[modify] https://crrev.com/7ef34f452a768d96ecf337cdaa45b795d190ecda/components/viz/service/display/surface_aggregator.cc
[modify] https://crrev.com/7ef34f452a768d96ecf337cdaa45b795d190ecda/components/viz/service/display/surface_aggregator_unittest.cc