Found this thread on Ask Ubuntu, but it got no answers: http://askubuntu.com/questions/849837/chrome-slow-in-16-10-with-multiple-windows-in-different-workspaces

Unable to reproduce issue on Ubuntu with chrome version #55.0.2883.87,tested the issue as per steps mentioned in the comment #0, observed that browser is working as expected.

Attaching the screen-cast for reference, could you please try the same scenario with clean profile with no apps & extensions and let us us know your observations.

Deleted: Issue 683486.mp4 9.8 MB

	Issue 683486.mp4 9.8 MB View Download

In your screen-cast, you opened two windows, but did not do step #3 (move one of those windows to another workspace, then try using the original window in the original workspace). Here is my screen-cast showing the problem.

Deleted: chromium_2.mp4 5.8 MB

	chromium_2.mp4 5.8 MB View Download

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

I am having this issue as well. 
Chrome 57.
Ubuntu 16.10
Intel i7 6700HQ, 16GB RAM, GTX 1060. 
I am running in Intel mode. So currently the Nvidia GPU is not in use. 
This does not happen when I am using Nvidia GPU mode. Only happens when I switch to Intel.

Navigation in both windows is extremely slow unless they are within the same workspace.  If I separate them, it's barely usable, but as soon as I place both windows within the same workspace, everything speeds up again (both windows).

Forgot to mention that a good way to test navigation is by hitting Ctrl-Tab multiple times (say 5+).  After 3, it starts slowing down when it wouldn't otherwise.

I am affected by the same bug with chrome Version 57.0.2987.133 (64-bit) on ubuntu 16.04.2.
$ uname -a
Linux xxxxx 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial

I checked that also with chromium I have the same problem

 Issue 683496  has been merged into this issue.

Could reproduce this issue:
Google Chrome: Version 58.0.3029.81 (64-bit)
Chromium: Version 57.0.2987.98 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)

$ uname -a
Linux 710s 4.8.0-46-generic #49~16.04.1-Ubuntu SMP Fri Mar 31 14:51:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial

I can reproduce this issue on Windows even with the fix for  issue 528803 .

There are two reasons for low frame rate with multiple windows:
1. Blocking in glXSwapBuffers because of using swap interval 1 with multiple windows. This was fixed in https://chromium-review.googlesource.com/479566 by porting the workaround that we used on Windows for a long time.
2. Blocking because the compositing manager has a reference to the backbuffer (a read lock) and we're trying to write to it. Nvidia driver seems to block in glXMakeCurrent for this.

X compositing managers can redirect Chrome's drawing to a pixmap and use GLX_EXT_texture_from_pixmaps to grab the backbuffer and composite it. The way it's usually done is (quoting the spec):
    -receive request for compositing:
    XGrabServer()
    glXWaitX() or XSync()
    glXBindTexImageEXT()

    <Do rendering/compositing>

    glXReleaseTexImageEXT()
    XUngrabServer()

<guesswork>

I took a cursory look at the compiz code and found that it decouples bind and release. It can bind the pixmap and not release it until later (probably when it decides to draw). There are quite a number of places in compiz code where it binds the texture.

Furthermore, on Nvidia the default option is to use buffer flipping. This means that binding the pixmap doesn't do a copy but rather blocks further rendering to that buffer by blocking in glXMakeCurrent.

I think there's a bug in compiz where it doesn't release the window's texture until later if the window is on a different workspace. This blocks make current in our GPU main thread and slows down other windows. I cannot reproduce this bug on other window managers. I suspect disabling buffer flipping in Nvidia settings will also workaround this bug.

</guesswork>

Given that unity and compiz are deprecatedI'm inclined to close this as WontFix but I'll wait until the above fix is merged to dev channel and we can confirm if that helps a bit.

Just because Unity does not have a long-term maintainer (at the moment) you are simply going to decline fixing the issue? That seems rather unreasonable. I'd like to encourage you to reconsider that hasty suggestion! Ubuntu 16.04 LTS is EOL in 2021, and even non-LTS releases that ship/will ship with Unity are going to be supported at least until mid-2018 or later. By declaring WontFix, you'd be essentially abandoning chromium (/chrome) users on Ubuntu running the default DE for several years.

Can you try the latest dev channel release (59.0.3071.25)? https://chromium-review.googlesource.com/479566 might have fixed the bug

I'm using the latest dev channel -- alas, it doesn't seem to help. :(

fwiw I can't reproduce it on Ubuntu 14.04. Has anyone been able to reproduce on that version?

No, I use 14.04.5 LTS (with latest LTS enablement stack) and I am not experiencing this particular issue either.

Can folks experiencing this issue paste the contents of the chrome://gpu page? (Don't save as HTML and attach, that doesn't work)

How about a PDF?  I'm on Ubuntu 17.04, but I first started noticing this issue on the last release, 16.10.

I was unaffected when I was using 16.04.

Deleted: chrome___gpu.pdf 111 KB

chrome___gpu.pdf 111 KB Download

Can you just copy the contents and put it in a text file? The chrome:// pages are special and a lot of things like printing, save to HTML, etc. don't work correctly I'm afraid.

Attached.

Deleted: chrome___gpu.txt 9.2 KB

chrome___gpu.txt 9.2 KB View Download

Here's mine.

Deleted: gpu.txt 21.5 KB

gpu.txt 21.5 KB View Download

Launching with LIBGL_DRI3_DISABLE=1 "fixes" the problem, so it's DRI3+modesetting again.

This happened once when Debian/Ubuntu defaulted to modesetting driver for Intel iGPUs, but now I'm seeing it with AMDGPU+RadeonSI after upgrading to X.Org Server to 1.19, which IIRC is the first one that uses xserver-xorg-video-amdgpu..

As mentioned in comment #28 I set the LIBGL_DRI3_DISABLE environment variable and could successfully use chromium window on separate workspaces with no slow down!

Ps: attaching chrome://gpu output as text.

Deleted: chrome-gpu-683486.txt 10.5 KB

chrome-gpu-683486.txt 10.5 KB View Download

Following this DRI3 Xorg feature, I found that it was not enabled on my setup.

So, I enabled it by adding the following into /etc/X11/xorg.conf:
Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   #Option      "SwapBuffersWait" "0"
   Option      "DRI" "3"
EndSection 

On reboot DRI3 enabling is logged:
$ cat /var/log/Xorg.0.log | grep DRI3
[     4.403] (II) intel(0): direct rendering: DRI2 DRI3 enabled

Then, chromium windows on multiple workspaces works with no slow down even without using the LIBGL_DRI3_DISABLE environment variable.

This might come also some performance benefit (and bugs?)...

I can confirm that the change suggested in Comment 31 currently works on my system.

OS Version: Ubuntu 17.04
Chrome Version: 58.0.3029.110 (64-bit)

However...

/etc/X11/xorg.conf does not exist by default. If you do not want to create this file (or Xorg is having trouble with -configure), you can also add the lines from Comment 31 into a new file - /usr/share/X11/xorg.conf.d/10-intel-chrome.conf

Adding the code in the way I mentioned above has worked for me, and has been persistent through several reboots/shutdowns, however I am somewhat newer to using Linux on such a "backend/granular" level. Can someone more experienced confirm that the 10-intel-chrome.conf file I referenced above is truly a persistent and 'good' solution?

Can confirm that the procedure in Comment 32 worked for me (Ubuntu 17.04).

You don't need to reboot -- you can do "sudo /etc/init.d/lightdm restart"