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

Issue 759188 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Feature



Sign in to add a comment

Have GPU Image Decode Cache handle Bitmap images

Project Member Reported by ericrk@chromium.org, Aug 25 2017

Issue description

Currently, the image decode caches ignore bitmap images, letting Skia use them directly. and in the GPU case, perform the upload.

We can probably manage the uploaded memory better as part of our image cache. We should see if the GPU cache can be adapted to process Bitmaps efficiently. I suspect this is just a case of skipping the decode task and adding a bit of handling to the upload task.
 

Comment 1 by ericrk@chromium.org, Feb 26 2018

Owner: khushals...@chromium.org
over to Khushal who has been working on this.

Comment 2 by ericrk@chromium.org, Feb 26 2018

Cc: ccameron@chromium.org ericrk@chromium.org
 Issue 660975  has been merged into this issue.
Handling of bitmaps is in but everything is done at-raster right now. 2 things that remain:

1) Create upload task without a decode dependency instead of doing it at-raster.

2) Make sure we save the result of color conversion for greater than max texture size image.
I presume for bitmap images, you mean non-lazy decoded images ?

So for "1" we shouldnt skip the the upload here, 
https://cs.chromium.org/chromium/src/cc/tiles/gpu_image_decode_cache.cc?type=cs&q=GetTaskForImageAndRefInternal&sq=package:chromium&l=664

But, i couldnt find any cond when we will not use the deferred img decoding (lazy decode) https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp?type=cs&l=179

Is there some use case when we are using non-lazy decode ?
Cc: sohanjg@chromium.org
These images are not coming from BitmapImage, you can create an SkImage backed by a SkBitmap. It would be better to use upload tasks for them instead of doing the upload at-raster. And yes, you should be able to do that by not skipping the upload task in GetTaskForImageAndRefInternal.
Project Member

Comment 7 by bugdroid1@chromium.org, May 4 2018

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

commit ce15d2f4607d6db583533c55999c8610ebb5e31f
Author: Khushal <khushalsagar@chromium.org>
Date: Fri May 04 23:47:41 2018

cc: Cache color converted bitmaps > max_texture_size in GpuCache.

Ensure that we cache the result of color conversion in the
GpuImageDecodeCache for images larger than max_texture_size, which are
color converted on the cpu during scaling.

R=ericrk@chromium.org

Bug:  791828 ,  759188 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0940e516ef6b36ccac961c1c15057eee2c73d64e
Reviewed-on: https://chromium-review.googlesource.com/1041465
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556257}
[modify] https://crrev.com/ce15d2f4607d6db583533c55999c8610ebb5e31f/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/ce15d2f4607d6db583533c55999c8610ebb5e31f/cc/tiles/gpu_image_decode_cache.h
[modify] https://crrev.com/ce15d2f4607d6db583533c55999c8610ebb5e31f/cc/tiles/gpu_image_decode_cache_unittest.cc

Status: Fixed (was: Assigned)

Sign in to add a comment