New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 724192 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Jun 2018
Cc:
█ aelias@chromium.org
ericrk@chromium.org
chrishtr@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Feature



Sign in to add a comment

Aggressive de-layerization on low-end Android

Project Member Reported by ericrk@chromium.org, May 18 2017 
Currently, Blink generates the same number of layers on low-end Android and full Android.

While we'll have more fine-grained control with SPV2, there may be a heavy "on-off" switch type approach we can use to reduce layers on low-end devices, under certain circumstances.

It would be worth doing a finch trial to go into a "minimal-layerization" mode for sites which meet some threshold (more than 3 layers deep, anywhere?).

Additionally, behavior like this could be used to mitigate memory usage on high-end machines with ultra-high-resolution monitors. See crbug.com/695427

Per chrishtr@'s comment on an email thread:

The simplest thing without sacrificing correctness is to turn off accelerated fixed-position and scrolling layers. The latter I don't think will help a lot, because there isn't a whole lot of non-root scrolling going on on mobile, but not accelerating fixed-position elements will reduce layer count and layer explosion. Furthermore, we could stop triggering compositing on "3D" matrices that are not actually 3D like translateZ(0), or will-change: transform.

We could also turn off accelerated canvas (which has probably already been discussed).

The rest of the compositing triggers (just went through the list) are mostly needed for correctness or because of their effect on composited descendants. The correctness ones are almost all related to 3D transforms. We could also turn off those triggers, and end up with output that is drawn incorrectly/flattened in many cases.

Comment 1 by aelias@chromium.org, May 18 2017

Cc: aelias@chromium.org
In the current architecture, not accelerating fixed-position layers also implies either A) disabling impl-thread scrolling, or B) incurring some truly atrocious "slippage" behavior.  I think either option would severely degrade the user experience would be reported by users as a P1 bug.

So although I think this is a good idea in theory, I would consider this blocked on SPv2+ lazy squashing such that we decouple impl-scrollability decision from squashing decision.  Ideally on these low-memory devices (just as with LCD text devices), we would scroll "thin" non-tile-holding layers on the impl-thread, then reraster every impl-frame into a squashed megalayer.

> We could also turn off accelerated canvas (which has probably already been discussed).

I think it hasn't, actually.  Canvas elements are rare on the web, anyway, so it probably doesn't much matter one way or the other.

Comment 2 by mariakho...@chromium.org, Jun 1 2017

Labels: LowMemory

Comment 3 by mariakho...@chromium.org, Jun 1 2017 

>> We could also turn off accelerated canvas (which has probably already been discussed).

> I think it hasn't, actually.  Canvas elements are rare on the web, anyway, so it probably doesn't much matter one way or the other.

junov@ looked at turning off accelerated canvas in 726462, but found that it was low savings and high performance cost.  Canvas is actually more common than you think (probably due to Ads use), we estimated through UMA to be 20% of web pages.

Comment 4 by schenney@chromium.org, Jun 2 2017

Labels: BugSource-Chromium PaintTeamTriaged-20170602
Project Member

Comment 5 by sheriffbot@chromium.org, Jun 4 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Comment 6 by chrishtr@chromium.org, Jun 4 2018

Status: WontFix (was: Untriaged)
This has been investigated in other bugs. Closing this one.
►

Sign in to add a comment