Hmm, +mlamouri. Does this happen with an 8k image as well? I can't think of anything specific to video which would affect this.

Nope, 8K images are apparently immune.

Interesting, I'll try it out tomorrow when I'm back at my desk and see what I can find out. +hubbe since he has a 4K display as well.

I can't seem to trigger this bug on chrome stable on Linux with a 4K display.

I just tried on a friend's machine and reproduced on a 1440p display; had to go up to 400% (or maybe 500%) zoom there before it reproduced.

I forgot to lock the video resolution to 8K.
Once I did that it reproduces on all my screens...

For what I can tell, the <video> element aspect ratio stays the same (1.77) and it seems that Chrome adds letter boxing when hitting 500%. I can't tell if that's on the layout or compositing side.

+some compositing and layout folks.

This would be a direct composited video, I think. Looping in those folks and Blink's video folks (that might be the same set of people already following).

schenney@ those folk are already on this bug :) As mounir notes in c#7 there seems to be some sort of letterbox being applied at high zoom levels.

I know pretty much nothing about how the video element is painted when it's directly composited. Is the issue the layer size that we're requesting of the GPU and/or the layout of the video tag?

Out of interest, what's the pixel width/height on a 8K display? Could we be trying to avoid short integer overflow of some kind at high zoom levels?

7680×4320 is the standard 8K resolution. The bug also reproduces on 1440p screens at higher zoom levels.

Been a minute. It's still embarrassing to demo 8K on Chrome, and I'd like to get in a fix in Stable before CES next January where 8K will likely be ubiquitous. Is there anything I can do to help this?

+liberato since he's been interested in getting into the compositing side of things more.

there is a VideoLayer on my linux box, and it does show the problem.

the bounds of the VideoLayer change abruptly from a ratio of 1.77 to 2.43 at 500% zoom on my linux machine.  makes me think that it's on the blink side, since the bounds are set pretty much directly.

if nobody's picked this up by the beginning of next week, then i'll look further.

Frank, want to pick this up or delegate for this Q?

cc:beccahughes since I see her fixing zoom issues :)

i'll take another look.

Frank, any updates here? Going to go ahead and tag this with a milestone and up the pri so it doesn't fall off our plate again.

no, i haven't gotten back to this yet.

seems to be bad math in LayoutUnit.

in a case with proper aspect ratio, LayoutSize::FitToAspectRatio computes the height as 1704*17280/30720 = 958.5 which is 1.77 aspect ratio (1704 / 958).

in a bad case, it computes the height as 1704*21600/38400 = 873, which is the wrong aspect ratio.  it's also just plain wrong.  bc tells me that it equals the same 958.5 .

probably could fix it with a call to ToFloat(), but i want to be sure that the overloaded ops aren't just broken.

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

commit 53479ca91ac63d89a22c06db86a4292edcb2fa65
Author: liberato@chromium.org <liberato@chromium.org>
Date: Tue Nov 28 19:19:33 2017

Avoid saturation when computing LayoutSize aspect ratio.

8k video could cause LayoutUnit to saturate multiplication when
computing the correct aspect ratio.  This CL does the calculation in
floating point, instead.

Bug:  728303 
Test: LayoutSizeTest
Change-Id: I632777e2f140b8203577b3e5e0761f3e7f891aa2
Reviewed-on: https://chromium-review.googlesource.com/773108
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519784}
[modify] https://crrev.com/53479ca91ac63d89a22c06db86a4292edcb2fa65/third_party/WebKit/Source/platform/BUILD.gn
[modify] https://crrev.com/53479ca91ac63d89a22c06db86a4292edcb2fa65/third_party/WebKit/Source/platform/geometry/LayoutSize.h
[add] https://crrev.com/53479ca91ac63d89a22c06db86a4292edcb2fa65/third_party/WebKit/Source/platform/geometry/LayoutSizeTest.cpp