Unable to reproduce the issue reported version on68.0.3399.0 using Win 7 & 10. Attaching Screencast for reference.

Steps 
--------
1. Launched Chrome 
2. Pressed ctrl+click ->navigated to given URL page and Observed page loading normally.
3. Copied the given URL and pasted in new tab, Observed page loading normally.

As we are unable to reproduce the issue from our end. Can you verify this issue with fresh profile that is not having any extensions and apps or reset all the flags. Let us know whether issue still persists.

Thanks! 

Deleted: 838006.mp4 920 KB

	838006.mp4 920 KB View Download

try to scroll the page down.
very slow on Version 68.0.3399.0 (Official Build) (64-bit)

no extensions

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

Unable to reproduce the issue on reported chrome version 68.0.3399.0 using Windows 10 with the below mentioned steps.
1. Launched chrome
2. Navigated to the URL provided in comment#0
3. Scrolled the page up/down.
We were able to scroll the page without any slowness. Attaching the screencast of the same.

@Rreporter: Could you please have a look at the screen cast and let us know if we have missed anything in the process. Any further inputs from your end may be helpful.

Thanks!

Deleted: 838006.mp4 6.9 MB

	838006.mp4 6.9 MB View Download

I found the problem!
To reproduce the bug just set Windows Scaling to 250% and then try to scroll. Chrome will consume 80% of CPU.

to set scaling go to:
Control Panel\All Control Panel Items\Display
then click at "Set a custom scaling level", select 250% and click OK, Apply, then Sign Out, login again and test Chromium.

set windows scaling to 250%, then open and scroll: https://github.com/Te-k/flexidie/blob/master/Android/2.07.1/source/daemon_im_capture/src/com/vvt/whatsapp/WhatsAppDatabaseObserver.java

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

Unable to reproduce the issue on reported chrome version 68.0.3399.0 using Windows 10 with the below mentioned steps.
Steps
---------
1. Changed system display settings to 250% as per comment #8
2. Launched chrome and navigated to the URL provided in comment#8
3. Scrolled the page up/down.
We were able to scroll the page without any slowness. Attaching the screencast of the same.

Adding UI>HighDPI as per C#8 and requesting someone from the respective team for help in further debugging.

@Reporter: Could you please provide the system detail and confirm whether the issue is seen only on M-68 and works fine on chrome stable

Thanks!

Deleted: 838006.mp4 7.6 MB

	838006.mp4 7.6 MB View Download

My system config: 8Gb ram, i7 cpu, Windows 10 x64 [Version 10.0.14393].
I have completed a couple of tests:
1. scaling 250% + small chromium window = no hiccups
2. scaling 250% + large chromium window = hiccups!
3. scaling 100% + small chromium window = no hiccups
I have attached videos.

Deleted: Recording #2.mp4 1.1 MB

	Recording #2.mp4 1.1 MB View Download

Deleted: Recording #3.mp4 2.4 MB

	Recording #3.mp4 2.4 MB View Download

Deleted: Recording #4.mp4 1.7 MB

	Recording #4.mp4 1.7 MB 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

I got the same results on:
Chromium Version 68.0.3424.0 (Official Build) (64-bit)
Microsoft Windows 10 x64 [Version 10.0.17134.1] version_1803_updated_march_2018
Chrome Version 66.0.3359.181 (Official Build) (64-bit)

Able to reproduce the issue on reported chrome version 68.0.3399.0,Beta 67.0.3396.40  & on latest chrome 68.0.3434.0 using Windows 7 &10. Hence providing bisect information below.
Unable to reproduce this issue on Ubuntu 17.10 and Mac(As we don't have High resolution>3836x1785 machine). 


Bisect Info:
================
Good build: 65.0.3292.0
Bad build: 65.0.3293.0


You are probably looking for a change made after 523314 (known good), but no later than 523328 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/6ff99f4c4670bd2cbd4232793518b4d0db619154..147039333ce317ccda28bd82ccc768a3317af2f8

suspect: https://chromium-review.googlesource.com/c/chromium/src/+/760997

Reviewed-on: Reviewed-on: https://chromium-review.googlesource.com/760997

@sunxd: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

Looking at this. This looks like a high-dpi problem.

Cannot reproduce on retina mac, seems like a windows specific issue.

I do not currently have a windows device with 4k display, will have to request one before I can debug this.

Hi enne@, do you know if we generate picture layer quads in a different way on windows compared to linux?

As this is regressed is M65 per comment #14, we won't consider this M67 stable blocker which is going to stable soon. Pls let us know ASAP if there is any  concern here. Thank you.

I'll remove release-block-stable for M67, we'll get this fixed in M68. The fix might influence other platforms' rendering process and trigger other regressions, so I do not feel safe to merge that fix into M67 without baking in canary. 

Re: comment #17.  Nope, there's nothing different about how we handle tile size decisions between Windows and Linux.

Thanks Enne.

Hi 470011@gmail.com, do you mind check if this still reproduces with running chrome with flag --disable-gpu? It will help identify whether it's a gl renderer problem or general one.

You can run in windows cmd with either:
start chrome --disable-gpu

or:
"<path-to-chrome>/chrome.exe" --disable-gpu

Thanks!

I confirm: the problem exists with or without "--disable-gpu"

Thank you for the feedback. weiliangc@ recently landed a fix on computing occlusion for mask layers, that might fix this bug as it reduces memory usage on border-radius layers. Do you mind checking if this bug persists with newest chrome canary (https://www.google.com/chrome/browser/canary.html)?

Chrome Version 68.0.3437.2 (Official Build) canary (64-bit)
bug still persists.

 Issue 844856  has been merged into this issue.

The issue does not reproduce with linux + 4k display + 200% scale, will now investigate on a windows machine.

sunxd@ -- I am running into this problem right now on my Windows machine.

I have a dual monitor setup. The problem happens when I move the Chrome window to my 4K display, but not on the non-4K display. Feel free to ping me for more details.

68.0.3437.2
{"arch":"x86-64","nacl_arch":"x86-64","os":"win"}

Hi vakh@, I just got my windows machine but still cannot reproduce this bug with 3840x2160 resolution, can you confirm that you are using 3836x1785 resolution?

Not the OP, but my similar issue was merged here. 

If it helps, I am facing similar issues on a windows laptop with a "15.6-inch UHD (3840 x 2160) IPS Anti-Glare LED-Backlit Display" at any scale above 100% .

no bug in Version 61.0.3163.79 (Official Build) (64-bit)

fixed at last.
Version 71.0.3556.0 (Official Build) (64-bit)