see attached. What is seen on failure -- preview image missing.

Deleted: previewmissing.jpg 27.2 KB

	previewmissing.jpg 27.2 KB View Download

see attached -- gpu setup on problem system

Deleted: gpu.txt 12.4 KB

gpu.txt 12.4 KB View Download

On the problem computer, I can get Canary to once again work with either "--disable-gpu-driver-bug-workarounds", or "--disable-gpu".

Can you check if this was caused by your change?

This could be a dupe of  issue 815045 . I'll confirm tomorrow.

jerryj@ Thanks for the issue.

Tested this issue on Windows 7,10 and Mac OS 10.12.6 on the latest Canary 66.0.3355.2(Revision-539001) and Beta 65.0.3325.88(Revision-530369) and unable to reproducer the issue by following the steps given above.

On navigating to the given link in the latest Canary, can observe that the image preview is seen without any issue.
Attached is the screen cast for reference.

As per comment #6, khushalsagar@ - you please confirm if this issue is related to  issue 815045 .

Thanks.. 

Deleted: 816046.mp4 1.5 MB

	816046.mp4 1.5 MB View Download

I too am unable to replicate on newer hardware.

The code path with the bug is almost certainly an 'exception' code path (gpu driver bug workaround) -- because when (on the problem system), I "--disable-gpu-driver-bug-workarounds", the bug goes away.

Are the errors/warnings inside the provided chrome://gpu output a clue?

One of the changes in the provided list is the cause.

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

Do you know what Chrome really needs....  The ability to ask Chrome for a command line that (when used) will run Chrome on another new computer that 'effectively' replicates the GPU setup (workarounds) from the older computer.

attached are gpu output from the two revs, if that helps.

Why would Optimus change?

Deleted: gpu-537367.txt 8.2 KB

gpu-537367.txt 8.2 KB View Download

Deleted: gpu-537380.txt 8.2 KB

gpu-537380.txt 8.2 KB View Download

This is the code that is failing:

  var ps = i.height/i.width;
  var pw = 300;
  var ph = Math.round(pw*ps);
  var xx = 5;
  var yy = elCanvas.height-ph-5;
  ctx.drawImage( i, xx, yy, pw, ph );

i.width is 5368
i.height is 977

--> drawImage fails for this image when 'pw' is less then or equal to 2684 (precisely half image width).  Namely, drawImage() starts working with pw=2685.

Hopefully a huge clue as the internal Chrome code path that is breaking?

I know don't think optimus is involved.  Turns out that is caused by 32/64 bit Chrome change.

Simply test on a Dell L702X notebook, Win 7 (or find another computer with same level of Intel graphics).

Some change in Canary made 10 days ago broke drawImage() on this computer.

jerryj@ Thanks for the feedback.

Retried the issue on Windows 7 on the latest Canary 66.0.3356.0(Revision-539380) and chrome version 66.0.3352.0(Revision-538313) and unable to reproduce the issue.

On navigating to the link given in comment #0 in the above chrome builds, the image preview is seen without any issues.
Attached is the screen casts and the gpu details for reference.

Removing the Needs-Bisect label as the issue is not reproducible at TE end.

Requesting someone from Internals>GPU>VendorSpecific team to please look into the issue and help in further triaging.

Thanks..

Deleted: 816046-r538313.mp4 3.6 MB

	816046-r538313.mp4 3.6 MB View Download

Deleted: 816046-latestCanary.mp4 5.1 MB

	816046-latestCanary.mp4 5.1 MB View Download

Deleted: gpu_LatestCanary.htm 112 KB

gpu_LatestCanary.htm 112 KB View Download

Deleted: gpu-r538313.htm 112 KB

gpu-r538313.htm 112 KB View Download

Today's Canary (66.0.3356.0) fixes the issue.  Bisect shows fixed between r539271 and r539279:

https://chromium.googlesource.com/chromium/src/+log/08761236b680c33428a485562d04e0a64b5a7404..41d56f974752011f030c5b2f63be331df960bad0

with the fix almost certainly:

  637c748 cc: Ensure correct scaling for non-lazy images in GPU cache

Khushal, thanks.  Also, maybe TE need some tips on how to better diagnose/reproduce these issues, as "the issue is not reproducible at TE end" and attempting to prove 'it works' when it clearly does not -- is not very helpful to anyone.

The status of this issue can be changed to fixed (by r539276)

Thanks for verifying jerry. I'll dupe this into  issue 815045  for archiving. FYI, that patch got reverted today: https://chromium-review.googlesource.com/c/chromium/src/+/939361. But I'll reland it soon.

khushals/18: thanks.  Can 815045 be made public, or must it remain private?

I've opened it, there isn't anything there for that bug to be private.