Just to check in, preliminary analysis is that this appears to be from us repainting the entire tab strip whenever we sneeze at it.

ccameron@ is there a good way to see where we're queueing images to decode? Not sure if this is favicons, paths that get cached to raster, something that happens at a higher level in the rasterization process or what.

vmiura@ told me that the reason that we're hitting "image decode" so much is that we're drawing by the sequence
- draw into a SkBitmap-backed SkCanvas
- draw that SkBitmap into the DisplayList-backed SkCanvas that we then use for raster

We should see if it's easier to do
- draw into a DisplayList-backed or SkPicture-backed SkCanvas
- draw "that thing" at raster-time

I don't know where this code lives though, so pointers there would be helpful for the investigation.

ImageSkia is the caching mechanism in the UI. All ImageSkiaSource for example return an ImageSkiaRep which is a bitmap. ImageSkia should be PaintOpBuffer-backed instead of bitmap-backed.

Some other old, and semi-related thoughts on ImageSkia: https://bugs.chromium.org/p/chromium/issues/detail?id=485770

Thanks!!

@sky: ^ what we were talking about the other day.

@sky: ^

Ah yes, ImageSkiaSource. I could see that being a bit painful in some cases to change to something else:(

Maybe this? https://bugs.chromium.org/p/chromium/issues/detail?id=851506#c26

Given c#3, this might not be the whole story, but could account for a lot of it.

c#10 was totally off base, that's a Cocoa issue.

ccameron@ for triage purposes, can we say that reducing paints would bump this down from a P1?

sky@, sadrul@, if this is ImageSkiaSource, then
- IIUC the issue is that those are SkBitmaps
- those bitmaps are coming from UI resources
- they aren't being rastered to (except perhaps for scaling)
- and they aren't being cached, and therefore are being re-uploaded every frame

If all of that is true, then the best fix would be to try to get these to hit the GpuImageDecodeCache.

(I need to verify that that is actually the case, though).

Hitting the cc cache requires using PaintImages with a consistent key. Its very likely that the UI is using the same bitmap (https://cs.chromium.org/chromium/src/ui/gfx/canvas.cc?type=cs&sq=package:chromium&g=0&l=361), but this is generating a new PaintImage key and causing re-uploads. 

Would using UIResourceLayer help with this kind of thing? (https://docs.google.com/document/d/1u9RZTyxdXP6zJ9skfanLPRowtvmciko95fZO1ZTZLiY/edit#heading=h.kj8klga3w5ys)

triage

> Would using UIResourceLayer help with this kind of thing? (https://docs.google.com/document/d/1u9RZTyxdXP6zJ9skfanLPRowtvmciko95fZO1ZTZLiY/edit#heading=h.kj8klga3w5ys)

It sounds like an option.  However if that results in making a layer or multiple layers per tab, that would add lots of compositing overhead for all frames even when the tab UI doesn't change.

Using a display list and making sure images have consistent cache keys would mean that re-rastering the tab wouldn't be so expensive, while number of composited layers stays lower.

> Using a display list and making sure images have consistent cache keys would mean that re-rastering the tab wouldn't be so expensive, while number of composited layers stays lower.

I think this is the way to go -- the traces that I've looked at spend most of their time uploading images both in the browser and in the GPU process.

The PaintCanvas::drawBitmap API is a bit of a footgun, since the callers don't realize that this will internally generate new cache keys and result in cache misses later. I'm going to kill it and replace everything with PaintCanvas::drawImage.

Change in review: https://chromium-review.googlesource.com/c/chromium/src/+/1110950

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/01e8678c66d897f0564a54d48291212ec5d2cbc9

commit 01e8678c66d897f0564a54d48291212ec5d2cbc9
Author: Khushal <khushalsagar@chromium.org>
Date: Tue Jun 26 21:10:53 2018

cc: Remove PaintCanvas::drawBitmap API.

The PaintCanvas API for drawing SkBitmaps has 2 short-comings when used
with a recording canvas:

1) It re-generates a PaintImage with a new key for potentially same
bitmaps.

2) It creates an internal SkImage wrapping this bitmap, which may incur
a copy of the pixels if the bitmap is not marked immutable.

Both of the above are also non-obvious from the API. Remove it and
switch callers to use PaintImages instead. The main user of this is ui/,
which already caches bitmaps for reuse in ImageSkiaRep. Also cache a
PaintImage with it to ensure we use a stable key for the bitmap.

R=danakj@chromium.org

Bug:  851282 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0ef7e8db798778b52b74a96dbf1a143fbead2ba9
Reviewed-on: https://chromium-review.googlesource.com/1110950
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570532}
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/paint_canvas.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/paint_image.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/paint_image.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/record_paint_canvas.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/record_paint_canvas.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/skia_paint_canvas.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/skia_paint_canvas.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/cc/paint/solid_color_analyzer_unittest.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/chrome/browser/ui/libgtkui/native_theme_gtk3.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/content/renderer/pepper/pepper_graphics_2d_host.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/content/renderer/pepper/pepper_plugin_instance_impl.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/content/renderer/pepper/pepper_plugin_instance_impl.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/content/renderer/sad_plugin.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/content/renderer/sad_plugin.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/third_party/blink/renderer/platform/graphics/paint/raster_invalidation_tracking.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/third_party/blink/renderer/platform/mac/graphics_context_canvas.mm
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/ui/gfx/BUILD.gn
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/ui/gfx/canvas.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/ui/gfx/image/image_skia_rep.cc
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/ui/gfx/image/image_skia_rep.h
[modify] https://crrev.com/01e8678c66d897f0564a54d48291212ec5d2cbc9/ui/native_theme/native_theme_win.cc