Unable to reproduce the issue on chrome reported version 64.0.3282.167 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://www.etymonline.com/
2) Clicked on imaged randomly
3) Didn't observed any mouse lags or interface freezing while image is loading, captured the results in the Devtools > Network tab

@Reporter:
Please find the attached screencast for your reference, try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks!

Deleted: 813436.ogv 12.4 MB

	813436.ogv 12.4 MB View Download

I don't think you are testing the same as I.

- You are using Chrome. I am using Chromium on openSUSE Leap 42.3
- You have JS and flash. I don't have flash installed and I have JS disabled.
- I don't click on images. I just load the main site.
- I use KDE Plasma 5.8.7. It is not clear what you use.
- It is not clear on what hardware you test, especially videocard and driver version (which I think may be related as I started to experience the issue just recently after a video driver update)
- Your command line flags don't match mine
- In your test you don't check the console output (which as seen on my video displays errors when the browser dev console is opened)

> try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

This is exactly how I test with additionally disabled:

chrome://settings/content/cookies
chrome://settings/content/location
chrome://settings/content/camera
chrome://settings/content/microphone
chrome://settings/content/notifications
chrome://settings/content/javascript
chrome://settings/content/flash
chrome://settings/content/backgroundSync
chrome://settings/content/automaticDownloads
chrome://settings/content/unsandboxedPlugins
chrome://settings/content/midiDevices
chrome://settings/content/protectedContent
chrome://settings/languages
chrome://settings/cloudPrinters

Please try to reproduce more accurately to the original. If any additional info is necessary please let me know.

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

Here is another recording showing a little better the issue.

(Please ignore the misplacement of HTML elements, this is due to the disabled JS)

Deleted: recording.ogv 3.4 MB

	recording.ogv 3.4 MB View Download

In the video the mouse cursor moves smoothly but in actuality it also freezes.

This is really terrible, especially with bigger images.

It seems (I am not 100% sure) it started to happen after updating the NVIDIA driver to version 390.25-10.1. With version 340.106 there was no such problem.

I hope you can have a look and prioritize this.

Turning off "Use hardware acceleration when available" seems to be a workaround for the issue however that messes up color management.

I hope someone is reading this.

Can you get the output of nvidia-smi -q when you encounter this issue? It's possible you're running out of GPU memory, but we'd like to confirm.

Tested with loading this image:

https://upload.wikimedia.org/wikipedia/commons/7/7a/Yunsup_Lee_holding_RISC_V_prototype_chip.jpg


[~]: nvidia-smi -q

==============NVSMI LOG==============

Timestamp                           : Fri Mar 16 20:52:32 2018
Driver Version                      : 390.42

Attached GPUs                       : 1
GPU 00000000:01:00.0
    Product Name                    : GeForce GTX 680
    Product Brand                   : GeForce
    Display Mode                    : N/A
    Display Active                  : N/A
    Persistence Mode                : Disabled
    Accounting Mode                 : N/A
    Accounting Mode Buffer Size     : N/A
    Driver Model
        Current                     : N/A
        Pending                     : N/A
    Serial Number                   : N/A
    GPU UUID                        : GPU-9d4daa58-de3a-146a-39f0-ff56e556edf5
    Minor Number                    : 0
    VBIOS Version                   : 80.04.09.00.E1
    MultiGPU Board                  : N/A
    Board ID                        : N/A
    GPU Part Number                 : N/A
    Inforom Version
        Image Version               : N/A
        OEM Object                  : N/A
        ECC Object                  : N/A
        Power Management Object     : N/A
    GPU Operation Mode
        Current                     : N/A
        Pending                     : N/A
    GPU Virtualization Mode
        Virtualization mode         : N/A
    PCI
        Bus                         : 0x01
        Device                      : 0x00
        Domain                      : 0x0000
        Device Id                   : 0x118010DE
        Bus Id                      : 00000000:01:00.0
        Sub System Id               : 0x353C1458
        GPU Link Info
            PCIe Generation
                Max                 : N/A
                Current             : N/A
            Link Width
                Max                 : N/A
                Current             : N/A
        Bridge Chip
            Type                    : N/A
            Firmware                : N/A
        Replays since reset         : 0
        Tx Throughput               : N/A
        Rx Throughput               : N/A
    Fan Speed                       : 40 %
    Performance State               : P0
    Clocks Throttle Reasons         : N/A
    FB Memory Usage
        Total                       : 1996 MiB
        Used                        : 668 MiB
        Free                        : 1328 MiB
    BAR1 Memory Usage
        Total                       : N/A
        Used                        : N/A
        Free                        : N/A
    Compute Mode                    : Default
    Utilization
        Gpu                         : N/A
        Memory                      : N/A
        Encoder                     : N/A
        Decoder                     : N/A
    Encoder Stats
        Active Sessions             : N/A
        Average FPS                 : N/A
        Average Latency             : N/A
    Ecc Mode
        Current                     : N/A
        Pending                     : N/A
    ECC Errors
        Volatile
            Single Bit            
                Device Memory       : N/A
                Register File       : N/A
                L1 Cache            : N/A
                L2 Cache            : N/A
                Texture Memory      : N/A
                Texture Shared      : N/A
                CBU                 : N/A
                Total               : N/A
            Double Bit            
                Device Memory       : N/A
                Register File       : N/A
                L1 Cache            : N/A
                L2 Cache            : N/A
                Texture Memory      : N/A
                Texture Shared      : N/A
                CBU                 : N/A
                Total               : N/A
        Aggregate
            Single Bit            
                Device Memory       : N/A
                Register File       : N/A
                L1 Cache            : N/A
                L2 Cache            : N/A
                Texture Memory      : N/A
                Texture Shared      : N/A
                CBU                 : N/A
                Total               : N/A
            Double Bit            
                Device Memory       : N/A
                Register File       : N/A
                L1 Cache            : N/A
                L2 Cache            : N/A
                Texture Memory      : N/A
                Texture Shared      : N/A
                CBU                 : N/A
                Total               : N/A
    Retired Pages
        Single Bit ECC              : N/A
        Double Bit ECC              : N/A
        Pending                     : N/A
    Temperature
        GPU Current Temp            : 41 C
        GPU Shutdown Temp           : N/A
        GPU Slowdown Temp           : N/A
        GPU Max Operating Temp      : N/A
        Memory Current Temp         : N/A
        Memory Max Operating Temp   : N/A
    Power Readings
        Power Management            : N/A
        Power Draw                  : N/A
        Power Limit                 : N/A
        Default Power Limit         : N/A
        Enforced Power Limit        : N/A
        Min Power Limit             : N/A
        Max Power Limit             : N/A
    Clocks
        Graphics                    : N/A
        SM                          : N/A
        Memory                      : N/A
        Video                       : N/A
    Applications Clocks
        Graphics                    : N/A
        Memory                      : N/A
    Default Applications Clocks
        Graphics                    : N/A
        Memory                      : N/A
    Max Clocks
        Graphics                    : N/A
        SM                          : N/A
        Memory                      : N/A
        Video                       : N/A
    Max Customer Boost Clocks
        Graphics                    : N/A
    Clock Policy
        Auto Boost                  : N/A
        Auto Boost Default          : N/A
    Processes                       : N/A


I don't think this is an out of GPU memory issue because I work with large images (30-50mpx and more) on this same computer every day. Also previously it has never been an issue with chromium too. It is a problem with chromium. Loading the same image in Firefox or IceCat is very fast and smooth and does not cause this freezing of the whole desktop.

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

ETA:

Clicking the same image with which I tested in order to zoom it causes freezing again. Clicking it again to zoom it back to fit takes even longer.

Perhaps it is an issue with rendering rather than loading.

Well, it sounds like a driver issue where sending heavy workloads to the GPU (ones that deal with large images) ends up blocking mouse cursor updates? These days all drivers/GPUs should be using hardware cursor planes which should update independently of GPU workloads, so if it doesn't happen, it is a problem in the X11 driver (either not using a hardware cursor plane, or blocking cursor updates until GPU work is done). You also mention that this happens after a driver update, so I'm not sure how much we can really do in Chrome? Besides disabling GPU acceleration (what you get by turning off "Use hardware acceleration when available"), which I don't think we want to do in the general case.

Maybe contact NVIDIA support?

As I explained I use heavy load graphics (2D and 3D) in various programs on a daily basis. Chromium is the only program which shows such issue and it started to show it fairly recently. I have been using Chromium for years and absolutely never experienced anything like that. I don't know if that is related to a version update of Chromium or of NVIDIA driver or of a particular combination of both.

You suggest to contact NVIDIA support but as long as all other apps work fine their reply will be 'Contact Chromium devs' and it makes sense.

So logically this really an issue with Chromium and needs to be investigated as such.

I can return the logic and mention that this works fine in Chrome on other drivers, so therefore it is a driver issue?

But more precisely, as I mentioned above, Chrome is not involved in moving the cursor on screen (that's the responsibility of the X11 driver, provided by NVIDIA). I'm not denying that Chrome may be submitting particular workloads that make the driver behave that way. But either way, we don't have source code for the NVIDIA driver so it's impossible for us to investigate what's happening there that makes cursor updates slow. NVIDIA people probably can, however.
If they can point at what specifically Chrome is doing that causes issues, I'm happy to look at whether there are alternatives. Though I still think that the driver should be able to handle whatever workload apps (Chrome or otherwise) are submitting, without holding up cursor updates.

This does not sound logical because:

1. You base this (quick) conclusion just on the added note I added in
comment 7 which was really just my speculation, not a proven fact. I
was merely trying to relate the issue to other changes on the system.
But the fact is that since then there have been 2 updates of the driver
and (I don't know how may) of Chromium. When I look at it now neither
with the older driver (considered non-problematic) nor with the newer
ones there are any issues in any program but Chromium. Currently I use:

[~]: rpm -q nvidia-glG04
nvidia-glG04-390.42-8.1.x86_64
[~]: rpm -q chromium
chromium-65.0.3325.162-146.1.x86_64

2. You talk about Chrome. I already pointed out that I am using
Chromium. I am not aware of the particular differences between the two
but AFAIK Google Chrome is not identical to Chromium.

3. I already explained that there is no driver issue with any other
program. I can start 10 or more 720p videos in mpv all playing in
parallel and there are no issues whatsoever (each shows 1% CPU in
system activity viewer). FWIW - I can do the same in 10 separate
chromium windows and they still play fine (with 1-3% load per process).
But when I load the image from the link above Chromium causes a peak
load in the system CPU. So merely assigning the issue to the GPU may not
be correct. I still notice that the zoom-to-fit of the image is much
slower than zooming in to 100% which makes me think that it is
something related to image scaling. Please check the attached
screenshot.

4. When you say "this works fine" - are you testing with this
particular (or at least similar) hardware and software? If not - then
your test will obviously show different results.

Considering all that: I am rather thinking this is unrelated to GPU at
all as the load is obviously on the CPU.

Another thing which comes to my mind (and again this is a speculation
just aimed to hopefully help you in pin-poining the source): since
Spectre and Meltdown were announced there have been some changes to
software (and browsers) in relation to which it was mentioned there may
be some performance degradation. Could it be something along these
lines? (still - I don't notice that in any other programs)

Obviously adding attachment when replying by email doesn't work for this site. So I am forced to visit the web page, enable non-free JavaScript to be executed on my computer and all that business...

Deleted: ksysguard-screenshot.png 123 KB

	ksysguard-screenshot.png 123 KB View Download

@#17:
1- This does not reproduce locally (local config: Quadro K2200
NVIDIA driver version 384.111), so it is driver-specific. But I was merely pointing out that the logic ("it doesn't happen in other apps than chrome therefore it's a bug in chrome") is flawed. As I mention again and again, on your system just as on mine, chrome (the executable) is not involved in the logic to move the cursor on screen, so it's pointless to try to find a bug in chrome until you identify what makes the cursor updates slow. NVIDIA people may be able to do that, but I can't.
2- Google Chrome is a product that uses the Chromium codebase. It's the same code. That said your distribution packaged their own build of Chromium, and I don't know what they may have changed in it, but we don't provide support for non-official builds of Chromium (you can ask your distribution).
3- HW video decoding has nothing to do with the GPU functionality we use to render images, so that's pretty irrelevant. Decoding large images will use the CPU, yes. For that matter, in Google Chrome (no idea about your distribution's Chromium-based browser) does rasterize pages (including images) on the CPU and uploads to the GPU for compositing. It is a spiky process, and it's definitely expected that it will take 100% of the number of cores dedicated to rasterization (which in Google Chrome will be between 1 and 4 with a max of half the number of CPUs) for a short while. You can play with the --num-raster-threads option if you wish. If the CPU load causes slow cursor updates (it doesn't here, even with a work load that pegs all CPU cores at 100%)
4- I will not attempt to replicate your exact configuration, sorry. I was pointing out exactly that, different configurations with the same chrome version don't experience the issue, so maybe you may want to consider that the issue is not necessarily in chrome?

Re Spectre mitigations, that's completely irrelevant here, you can read about them at https://www.chromium.org/Home/chromium-security/ssca but they only affect Javascript execution (it sounds like you have disabled it, but either way is irrelevant for rendering). Meltdown mitigations are done at the kernel level, so that's by your distribution and irrelevant here.

You are testing on completely different hardware and software and use this as a basis to argue that the issue is not reproducible. Through that you insist that the bug reporter should become a mediator between you an NVIDIA telling them "Someone claims there is a problem in your driver but personally I have no complaints as all programs except this one work fine. Still I am contacting you just because I am not getting any help from chromium devs". Obviously that is quite meaningless. If you insist on that route you must provide a procedure which proves that the problem is in the video driver, just like I have demonstrated that the lagging is caused by CPU overload. Otherwise there is simply nothing to show to NVIDIA and we are all wasting time. Without actual debug info NVIDIA cannot possibly give any meaningful feedback which you could use. Merely disabling/enabling hardware acceleration in chromium to demonstrate that it *may* be related to video driver does _not mean_ the problem is in the driver. NVIDIA may argue that their driver is fine and that the way you (chromium code) uses it is buggy.

So please provide a procedure for sending proper debug info to NVIDIA proving that the problem is in the driver. Then I will contact them.

Right after submitting this comment I will also file a bug at openSUSE's bugzilla as you seem to question their binaries too.

It seems the issue was with openSUSE's build.
They released an update and in version 66.0.3359.117 it works as expected.

Sorry for the trouble.

Can you point to the openSUSE bug so that we know what the problem was?

https://bugzilla.suse.com/show_bug.cgi?id=1086199

But it contains no info about the actual reason for the problem.