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

Issue 649184 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocking:
issue 648644
issue 643850



Sign in to add a comment

smoothness.tough_animation_cases overlay_background_color_css_transitions.html is slow with GPU rasterization

Project Member Reported by jbau...@chromium.org, Sep 21 2016

Issue description

On my system it went from 120 ms/frame with software to 800 ms/frame with GPU rasterization. I've attached a trace when rasterizing using my Quadro 600 - it seems like a small number of GPU commands are taking an incredible long time to execute
 
trace_overlay_background_color_css_transitions_gpu.json.gz
2.1 MB Download
Blocking: 643850

Comment 2 by ericrk@chromium.org, Mar 30 2017

Status: WontFix (was: Available)
Just tested this locally, and I'm only seeing a small (10%) decrease due to GPU raster. However, either way, I don't really feel like this is a real scenario. The test in question:

- Sets up 500 divs on top of each-other, each with 0.5 opacity.
- Adds a transform-z to these so we create a CC layer for each.
- Tries to smoothly change the color of all 500 divs at the same time.

This ends up turning into rasterizing / compositing 1000 tiles a frame, which swamps the compositor is very inefficient in terms of tile rasterization (lots of skia / draw call overhead, very little batching).

As a point of comparison, if we get rid of the translate-z and let Skia handle all this overdraw internally, GPU raster runs at 60hz and is 2.5x faster than SW.

This test may be useful to catch compositor regressions, but I'm not sure it's a useful comparison point for GPU vs SW raster.

There may be ways to optimize this, but I'm not sure it's worth it?


Sign in to add a comment