New issue
Advanced search Search tips

Issue 813740 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 27
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Chromium rendering page and scrolling very slow when Marco compositing is enabled after upgrading to Mate 1.20

Reported by linuxjus...@gmail.com, Feb 20 2018

Issue description

Chrome Version (from the about:version page): 64.0.3282.167
Is this the most recent version: yes
OS + version: ArchlinuxArm
CPU architecture (32-bit / 64-bit): 64-bit aarch64
Window manager: Marco (Mate desktop)
Behavior in Linux Firefox: No such issue at all

What steps will reproduce the problem?
(1) Get a device using LLVMpipe to render (Mine is Chromebook Plus)
(2) Enable compositing in Mate desktop
(3) Open Chromium/Chrome
(4) Open a web page, scroll up and down, you might find it's slow, and can see "tearing" clearly.
(5) Disable compositing in Marco, scroll smoothly, no tearing exists.

What is the expected result?
Chromium should render page as normal, scroll smoothly.


What happens instead?
Open a web page, scroll up and down, you might find it's slow, and can see "tearing" clearly.


Please provide any additional information below. Attach a screenshot
and backtrace if possible.
Well, for cross reference, there is an related issue report on Marco: https://github.com/mate-desktop/marco/issues/390

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

The result of "about:gpu" is in attachment.
 
gpu.html
61.3 KB View Download
Labels: Needs-Triage-M64
Labels: Triaged-ET OS-Chrome
The issue seems to be related to chrome OS. Hence, adding appropriate OS label.
Labels: -OS-Linux
Well, although my computer is Chromebook, I installed ArchLinuxArm there, so it's platform is Linux rather than ChromeOS.
Components: Internals>GPU
Status: WontFix (was: Unconfirmed)
We probably won't be able to test this specific set up right now. On the github issue seems like a workaround has been found. I'm going to close this bug. If issue persists or you found out more about what is causing this, please file a new bug.

Thank you.

Sign in to add a comment