I can't repro this anywhere. And I wonder if I could even see the difference if I could.

My suggestion: try to make this into a simpler JS with way easier contrast on the change. But you do win the "most complicated way to set width/height of a canvas award".

This could be related to chrome changing from accelerated to non-accelerated Canvas (because you are using get/putImageData). It could also be due to the fact that you are stretching the canvas on CSS. Try to "image-rendering: pixelated" option to your canvas style and see if it repros again.

The test case is generated programmatically, so we are sorry for the complicatedness. However, this seems to be a timing issue, because if we modify the test case in any way, it doesn't reproduce the issue. Here we are uploading does-not-reproduce.htm file, which does basically the same thing that the original script does, but this one is more readable. However, it doesn't reproduce the issue.

We also observed that '#222' can be replaced with any other color and still reproduce the issue. For the best contrast, replace it with 'white'. Also if it can't be seen properly on the original screencast due to mp4 compression, the canvas looks like CSS "image-rendering" is set to "pixelated". The issue is that it doesn't happen only on loading the page, but randomly after 3-5 seconds after the page loads.

If nobody is able to reproduce the issue, we can upload our win10 virtual machine and share the link here. However, it should be the last resort, since the machine is ~20GB.

Deleted: does-not-reproduce.htm 592 bytes

does-not-reproduce.htm 592 bytes View Download

Able to reproduce the issue on Win-10 and Ubuntu 17.10 using chrome reported version #70.0.3538.77 and latest canary #72.0.3596.0. Issue is not seen in OS-Mac.
This is a non-regression issue as it is observed from M60 old builds. 
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

I also can't reproduce it. I see the first rendering looking pixelated then going to smoothed. The bug report seems to indicate the opposite is happening.

My guess is that the filtering method is changing for some reason, but the only way we modify the interpolation quality is via a ScopedInterpolationQuality object and it seems hard to construct a race condition there.

On Windows I also have the screen scale set to 125%, but the outcome is the same at 100%.

Regardless, we would have to be able to reproduce it, and we can't. Maybe a slow machine is required?

What if you disable Hardware Accelerated Canvas in chrome://flags? Or force it on, because I suspect the virtual machine does not enable hardware acceleration.

Re C#6:

That is correct, the issue is that the canvas is pixelated not only while loading the page (but we don't see the reason for it to be pixelated even when loading), but it is also pixelated after it becomes smooth once.

The virtual machine actually supports acceleration, but note that the issue is observed both on win10 virtual machine and win8 real machine. We tested both on real and virtual machine with "Accelerated 2D canvas" from chrome://flags disabled and observed that the issue doesn't reproduce. When such feature is disabled, the canvas is smooth even on loading the page.

We also noticed that opening any folder from bookmarks bar while the test case is open, the canvas becomes pixelated immediately, but only once until the page is refreshed again. We also observed that switching tabs using Ctrl+Tab sometimes triggers the issue.

The user from C#4 says they are able to reproduce the issue, so we are wondering can someone from dev team investigate their environment instead of our virtual machine. We can start uploading our VM, but it will probably take few weeks to upload because of our slow internet. Or even better, if someone still has our machine from  bug 875285 , it is the same machine, so just paste the index.htm there. If not, we will upload again.

Also from C#6: "I see the first rendering looking pixelated" - isn't it already invalid behavior? Despite the fact that it becomes pixelated later again, even on the first load it should not look like that. It doesn't look like that in any other browser we tested so far. And we are using requestAnimationFrame, not setTimeout.

I'm trying to reproduce this, and I just want to make sure I understand what I'm looking for. The pixelation you're seeing is on the extremely faint grey crosshatches on top of the black canvas background? I agree with c#2 - I'm not sure I could even see that if it were happening. I'm guessing we don't have a machine problem here (i.e. no need to download the virtual machine), I think we have a need for a better repro on this. Is there any better example with a real, visible image on the canvas?

As we said in C#3, the color (both bg and fg) doesn't affect the issue. For the best contrast use `black` for bg color and `white` instead of `#222`. The difference is actually very noticeable, as can be seen on the two screenshots here. Also said in C#3: the canvas looks exactly like CSS image-rendering is set to "pixelated", so in order to deliberately force the canvas to be pixelated, configure such CSS property. Not sure there is an example of better contrast than what we've explained. The issue is even more noticeable on small resolution monitors (1920x1080 and 1024x768).

Deleted: smooth.png 112 KB

	smooth.png 112 KB View Download

Deleted: pixelated.png 70.7 KB

	pixelated.png 70.7 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Bisected to r461232 = 9b1ac7f2a38585c066bc6523e0c08aeb1adbf171 = https://crrev.com/2788583002 by xiangze.zhang@intel.com
"Reland of "Make disabling 2d canvas GPU acceleration for getImageData less aggressive.""
Landed in 59.0.3059.0

Able to reproduce the issue on Windows 10 and Ubuntu 17.10 on the latest Stable 70.0.3538.102 and the latest Canary 72.0.3610.0 as mentioned in comment #4.
Issue is not observed on Mac OS 10.13.6.

This is a Non-Regression issue as this is observed from M-60 chrome builds.
Attached is the screen cast for reference.

Hence marking this as Untriaged for further updates from Dev.

Thanks..

Deleted: 899385-M60.mp4 4.1 MB

	899385-M60.mp4 4.1 MB View Download

Thanks for the info and repro information. Based on the bisect and description, I'm changing components to GPU>Canvas2D.

fserb@, can you take a look?

I can reproduce this issue and it is not really related to my patch. 

I see getImageData changes the canvas's underlying GL texture's GL_TEXTURE_MAG_FILTER state to GL_NEAREST.

In cc, when composting the canvas element, the filter state should be GL_LINEAR, but it is cached and not always set when binding texture: https://cs.chromium.org/chromium/src/components/viz/service/display/display_resource_provider.cc?rcl=437630830a6eae058218f49808dfeea74c45c445&l=594

A simple fix is to always set filter when binding texture. Or we need to stop getImageData from messing with canvas's state.

It does appear as if xiangze.zhang's fix works. Is there any reason to perform that check? It seems to me like there's no advantage to doing it.

"I see getImageData changes the canvas's underlying GL texture's GL_TEXTURE_MAG_FILTER state to GL_NEAREST"

@xiangze.zhang can you tell me where this is happening?

This CL just deletes the check and fixes the bug:
https://chromium-review.googlesource.com/c/chromium/src/+/1426063

If I remember correctly, it's happened in skia gpu backend's readSurfacePixels:

https://cs.chromium.org/chromium/src/third_party/skia/src/gpu/GrContext.cpp?rcl=9a9f3aca2b1e8cd22f4b2a4610e33df762ca1614&l=756

If that's the case, is Canvas2D the appropriate component for this bug?