skia: Use discardable memory for scaled image cache.

skia: Use discardable memory for scaled image cache.

BUG=276675
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=243592

[reveman, 2013-12-10 00:32:47]

The discardable memory implementation still needs some tuning but it should be
safe to turn this on by default as it will only be used with impl-side painting
on non-android.

[reed1, 2013-12-10 16:50:04]

On 2013/12/10 00:32:47, David Reveman wrote:
> The discardable memory implementation still needs some tuning but it should be
> safe to turn this on by default as it will only be used with impl-side
painting
> on non-android.

Hmmm, we are seeing usage of High Quality image filtering in chrome, which
triggers the use of the scaledimagecache. Are you sure it is not actively being
used today in chrome?

[reveman, 2013-12-10 17:09:58]

+ernstm, humper, hclam

I thought scaledimagecache was only used for SkPicture playback and blink would
still do the scaling and caching when SkPictures are not used. Is that not the
case?

Even if limited to SkPicture playback, I guess the browser compositor on
ChromeOS will trigger usage of scaledimagecache as it's using per-tile painting.
Not sure high quality filtering is ever used in that case though.

[reed1, 2013-12-10 17:15:58]

On 2013/12/10 17:09:58, David Reveman wrote:
> +ernstm, humper, hclam
> 
> I thought scaledimagecache was only used for SkPicture playback and blink
would
> still do the scaling and caching when SkPictures are not used. Is that not the
> case?
> 
> Even if limited to SkPicture playback, I guess the browser compositor on
> ChromeOS will trigger usage of scaledimagecache as it's using per-tile
painting.
> Not sure high quality filtering is ever used in that case though.

ScaledImageCache is used whenever we see a HQ filter request. I don' know when
chrome/blink decide to request that.

[Alpha Left Google, 2013-12-10 20:13:05]

We decide to do high quality resampling here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

What it means is that: if the image is lazy decoded and awsome is chosen
then we do high quality resampling. Awsome is on by default for all images
on desktop. Awsome is off by default on android.

Now looking at the code I think there's a problem that high quality
resampling is not on with the new skia discardable memory path. I'll fix
that.

Alpha


2013/12/10 <reed@google.com>

> On 2013/12/10 17:09:58, David Reveman wrote:
>
>> +ernstm, humper, hclam
>>
>
>  I thought scaledimagecache was only used for SkPicture playback and blink
>>
> would
>
>> still do the scaling and caching when SkPictures are not used. Is that
>> not the
>> case?
>>
>
>  Even if limited to SkPicture playback, I guess the browser compositor on
>> ChromeOS will trigger usage of scaledimagecache as it's using per-tile
>>
> painting.
>
>> Not sure high quality filtering is ever used in that case though.
>>
>
> ScaledImageCache is used whenever we see a HQ filter request. I don' know
> when
> chrome/blink decide to request that.
>
> https://codereview.chromium.org/110863003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reed1, 2013-12-10 20:22:37]

Alpha,

Now that scaledimagecache is available, why should we continue to resample
in HW on the pixelref side?


On Tue, Dec 10, 2013 at 3:13 PM, Alpha Lam <hclam@chromium.org> wrote:

> We decide to do high quality resampling here:
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
>
> What it means is that: if the image is lazy decoded and awsome is chosen
> then we do high quality resampling. Awsome is on by default for all images
> on desktop. Awsome is off by default on android.
>
> Now looking at the code I think there's a problem that high quality
> resampling is not on with the new skia discardable memory path. I'll fix
> that.
>
> Alpha
>
>
> 2013/12/10 <reed@google.com>
>
> On 2013/12/10 17:09:58, David Reveman wrote:
>>
>>> +ernstm, humper, hclam
>>>
>>
>>  I thought scaledimagecache was only used for SkPicture playback and blink
>>>
>> would
>>
>>> still do the scaling and caching when SkPictures are not used. Is that
>>> not the
>>> case?
>>>
>>
>>  Even if limited to SkPicture playback, I guess the browser compositor on
>>> ChromeOS will trigger usage of scaledimagecache as it's using per-tile
>>>
>> painting.
>>
>>> Not sure high quality filtering is ever used in that case though.
>>>
>>
>> ScaledImageCache is used whenever we see a HQ filter request. I don' know
>> when
>> chrome/blink decide to request that.
>>
>> https://codereview.chromium.org/110863003/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reveman, 2013-12-10 20:24:13]

On 2013/12/10 20:13:05, Alpha wrote:
> We decide to do high quality resampling here:
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
> 
> What it means is that: if the image is lazy decoded and awsome is chosen
> then we do high quality resampling. Awsome is on by default for all images
> on desktop. Awsome is off by default on android.

Ok, good. It should then be safe to turn this on as we only use lazy decode with
impl-side painting. Per-tile painting used by the browser compositor doesn't use
this.

> 
> Now looking at the code I think there's a problem that high quality
> resampling is not on with the new skia discardable memory path. I'll fix
> that.
> 

Thanks.

[Alpha Left Google, 2013-12-10 20:38:50]

2013/12/10 Mike Reed <reed@google.com>

> Alpha,
>
> Now that scaledimagecache is available, why should we continue to resample
> in HW on the pixelref side?
>

I'm not familiar with hardware resampling in blink. Maybe David would know.

Alpha


>
>
> On Tue, Dec 10, 2013 at 3:13 PM, Alpha Lam <hclam@chromium.org> wrote:
>
>> We decide to do high quality resampling here:
>>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
>>
>> What it means is that: if the image is lazy decoded and awsome is chosen
>> then we do high quality resampling. Awsome is on by default for all images
>> on desktop. Awsome is off by default on android.
>>
>> Now looking at the code I think there's a problem that high quality
>> resampling is not on with the new skia discardable memory path. I'll fix
>> that.
>>
>> Alpha
>>
>>
>> 2013/12/10 <reed@google.com>
>>
>> On 2013/12/10 17:09:58, David Reveman wrote:
>>>
>>>> +ernstm, humper, hclam
>>>>
>>>
>>>  I thought scaledimagecache was only used for SkPicture playback and
>>>> blink
>>>>
>>> would
>>>
>>>> still do the scaling and caching when SkPictures are not used. Is that
>>>> not the
>>>> case?
>>>>
>>>
>>>  Even if limited to SkPicture playback, I guess the browser compositor on
>>>> ChromeOS will trigger usage of scaledimagecache as it's using per-tile
>>>>
>>> painting.
>>>
>>>> Not sure high quality filtering is ever used in that case though.
>>>>
>>>
>>> ScaledImageCache is used whenever we see a HQ filter request. I don'
>>> know when
>>> chrome/blink decide to request that.
>>>
>>> https://codereview.chromium.org/110863003/
>>>
>>
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reed1, 2013-12-10 21:06:58]

Sorry, I mistyped. I meant to ask, why should we continue to resample in
the PixelRef at all, instead of always using scaledimagecache?


On Tue, Dec 10, 2013 at 3:38 PM, Alpha Lam <hclam@chromium.org> wrote:

>
>
>
> 2013/12/10 Mike Reed <reed@google.com>
>
>> Alpha,
>>
>> Now that scaledimagecache is available, why should we continue to
>> resample in HW on the pixelref side?
>>
>
> I'm not familiar with hardware resampling in blink. Maybe David would know.
>
> Alpha
>
>
>>
>>
>>  On Tue, Dec 10, 2013 at 3:13 PM, Alpha Lam <hclam@chromium.org> wrote:
>>
>>> We decide to do high quality resampling here:
>>>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
>>>
>>> What it means is that: if the image is lazy decoded and awsome is chosen
>>> then we do high quality resampling. Awsome is on by default for all images
>>> on desktop. Awsome is off by default on android.
>>>
>>> Now looking at the code I think there's a problem that high quality
>>> resampling is not on with the new skia discardable memory path. I'll fix
>>> that.
>>>
>>> Alpha
>>>
>>>
>>> 2013/12/10 <reed@google.com>
>>>
>>> On 2013/12/10 17:09:58, David Reveman wrote:
>>>>
>>>>> +ernstm, humper, hclam
>>>>>
>>>>
>>>>  I thought scaledimagecache was only used for SkPicture playback and
>>>>> blink
>>>>>
>>>> would
>>>>
>>>>> still do the scaling and caching when SkPictures are not used. Is that
>>>>> not the
>>>>> case?
>>>>>
>>>>
>>>>  Even if limited to SkPicture playback, I guess the browser compositor
>>>>> on
>>>>> ChromeOS will trigger usage of scaledimagecache as it's using per-tile
>>>>>
>>>> painting.
>>>>
>>>>> Not sure high quality filtering is ever used in that case though.
>>>>>
>>>>
>>>> ScaledImageCache is used whenever we see a HQ filter request. I don'
>>>> know when
>>>> chrome/blink decide to request that.
>>>>
>>>> https://codereview.chromium.org/110863003/
>>>>
>>>
>>>
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reed1, 2013-12-10 21:07:56]

If you're going to enable this new experimental backend, how will you
measure the result? i.e. how can we know if we have improved or hurt
chrome's overall performance?


On Tue, Dec 10, 2013 at 3:24 PM, <reveman@chromium.org> wrote:

> On 2013/12/10 20:13:05, Alpha wrote:
>
>> We decide to do high quality resampling here:
>>
>
> https://code.google.com/p/chromium/codesearch#chromium/
> src/third_party/WebKit/Source/platform/graphics/skia/
> NativeImageSkia.cpp&l=364
>
>  What it means is that: if the image is lazy decoded and awsome is chosen
>> then we do high quality resampling. Awsome is on by default for all images
>> on desktop. Awsome is off by default on android.
>>
>
> Ok, good. It should then be safe to turn this on as we only use lazy
> decode with
> impl-side painting. Per-tile painting used by the browser compositor
> doesn't use
> this.
>
>
>
>  Now looking at the code I think there's a problem that high quality
>> resampling is not on with the new skia discardable memory path. I'll fix
>> that.
>>
>
>
> Thanks.
>
> https://codereview.chromium.org/110863003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alpha Left Google, 2013-12-10 21:18:19]

2013/12/10 Mike Reed <reed@google.com>

> Sorry, I mistyped. I meant to ask, why should we continue to resample in
> the PixelRef at all, instead of always using scaledimagecache?
>

In the new skia discardable memory path all* PixelRefs are original bitmaps
without custom resampling. We just let Skia do resampling and utilize
ScaledImageCache.

* Not exactly all. Android has a special path to asking decoder to do
downsampling internally. But this is not used on desktop. We should
probably find a good solution to replace this in the future.

Alpha


>
>
> On Tue, Dec 10, 2013 at 3:38 PM, Alpha Lam <hclam@chromium.org> wrote:
>
>>
>>
>>
>> 2013/12/10 Mike Reed <reed@google.com>
>>
>>> Alpha,
>>>
>>> Now that scaledimagecache is available, why should we continue to
>>> resample in HW on the pixelref side?
>>>
>>
>> I'm not familiar with hardware resampling in blink. Maybe David would
>> know.
>>
>> Alpha
>>
>>
>>>
>>>
>>>  On Tue, Dec 10, 2013 at 3:13 PM, Alpha Lam <hclam@chromium.org> wrote:
>>>
>>>> We decide to do high quality resampling here:
>>>>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
>>>>
>>>> What it means is that: if the image is lazy decoded and awsome is
>>>> chosen then we do high quality resampling. Awsome is on by default for all
>>>> images on desktop. Awsome is off by default on android.
>>>>
>>>> Now looking at the code I think there's a problem that high quality
>>>> resampling is not on with the new skia discardable memory path. I'll fix
>>>> that.
>>>>
>>>> Alpha
>>>>
>>>>
>>>> 2013/12/10 <reed@google.com>
>>>>
>>>> On 2013/12/10 17:09:58, David Reveman wrote:
>>>>>
>>>>>> +ernstm, humper, hclam
>>>>>>
>>>>>
>>>>>  I thought scaledimagecache was only used for SkPicture playback and
>>>>>> blink
>>>>>>
>>>>> would
>>>>>
>>>>>> still do the scaling and caching when SkPictures are not used. Is
>>>>>> that not the
>>>>>> case?
>>>>>>
>>>>>
>>>>>  Even if limited to SkPicture playback, I guess the browser compositor
>>>>>> on
>>>>>> ChromeOS will trigger usage of scaledimagecache as it's using per-tile
>>>>>>
>>>>> painting.
>>>>>
>>>>>> Not sure high quality filtering is ever used in that case though.
>>>>>>
>>>>>
>>>>> ScaledImageCache is used whenever we see a HQ filter request. I don'
>>>>> know when
>>>>> chrome/blink decide to request that.
>>>>>
>>>>> https://codereview.chromium.org/110863003/
>>>>>
>>>>
>>>>
>>>
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reveman, 2013-12-10 23:32:10]

On 2013/12/10 21:07:56, reed1 wrote:
> If you're going to enable this new experimental backend, how will you
> measure the result? i.e. how can we know if we have improved or hurt
> chrome's overall performance?

This is only for impl-side painting on ChromeOS with emulated discardable memory
for now. More direct scaledimagecache vs ImageDecodingStore performance
measurements will be needed before we can turn this on for a different
configuration.

The performance comparison we're interested in right now is impl-side painting
with scaledimagecache vs non-impl-side painting on ChromeOS. If we can enable
impl-side painting with the benefits we get from that without increasing overall
memory usage of chrome, I think that's a success.

> 
> 
> On Tue, Dec 10, 2013 at 3:24 PM, <mailto:reveman@chromium.org> wrote:
> 
> > On 2013/12/10 20:13:05, Alpha wrote:
> >
> >> We decide to do high quality resampling here:
> >>
> >
> > https://code.google.com/p/chromium/codesearch#chromium/
> > src/third_party/WebKit/Source/platform/graphics/skia/
> > NativeImageSkia.cpp&l=364
> >
> >  What it means is that: if the image is lazy decoded and awsome is chosen
> >> then we do high quality resampling. Awsome is on by default for all images
> >> on desktop. Awsome is off by default on android.
> >>
> >
> > Ok, good. It should then be safe to turn this on as we only use lazy
> > decode with
> > impl-side painting. Per-tile painting used by the browser compositor
> > doesn't use
> > this.
> >
> >
> >
> >  Now looking at the code I think there's a problem that high quality
> >> resampling is not on with the new skia discardable memory path. I'll fix
> >> that.
> >>
> >
> >
> > Thanks.
> >
> > https://codereview.chromium.org/110863003/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[reveman, 2013-12-12 16:32:56]

ping

[reed1, 2013-12-12 19:20:09]

On 2013/12/12 16:32:56, David Reveman wrote:
> ping

Since you have identified bugs in the discardable version of scaledimagecache, I
am presuming you don't want to enable it yet. Is that not the case?

[reveman, 2013-12-12 19:34:33]

On 2013/12/12 19:20:09, reed1 wrote:
> On 2013/12/12 16:32:56, David Reveman wrote:
> > ping
> 
> Since you have identified bugs in the discardable version of scaledimagecache,
I
> am presuming you don't want to enable it yet. Is that not the case?

I'm ok enabling this before that's fixed as we still need to turn on impl-side
painting on a non-android platform for this to be used anywhere.

[reed1, 2013-12-12 19:53:23]

On 2013/12/12 19:34:33, David Reveman wrote:
> On 2013/12/12 19:20:09, reed1 wrote:
> > On 2013/12/12 16:32:56, David Reveman wrote:
> > > ping
> > 
> > Since you have identified bugs in the discardable version of
scaledimagecache,
> I
> > am presuming you don't want to enable it yet. Is that not the case?
> 
> I'm ok enabling this before that's fixed as we still need to turn on impl-side
> painting on a non-android platform for this to be used anywhere.

Hmmm, we see the scaledimagecache getting used today on desktops, so I'm not
sure we should enable a change to code that is known to have bugs. Help me
understand why it is better to enable this now.

[reveman, 2013-12-12 20:26:13]

On 2013/12/12 19:53:23, reed1 wrote:
> On 2013/12/12 19:34:33, David Reveman wrote:
> > On 2013/12/12 19:20:09, reed1 wrote:
> > > On 2013/12/12 16:32:56, David Reveman wrote:
> > > > ping
> > > 
> > > Since you have identified bugs in the discardable version of
> scaledimagecache,
> > I
> > > am presuming you don't want to enable it yet. Is that not the case?
> > 
> > I'm ok enabling this before that's fixed as we still need to turn on
impl-side
> > painting on a non-android platform for this to be used anywhere.
> 
> Hmmm, we see the scaledimagecache getting used today on desktops, so I'm not
> sure we should enable a change to code that is known to have bugs. Help me
> understand why it is better to enable this now.

Where are you seeing scaledimagecache getting used on desktop today? Local
build?

Based on what Alpha said earlier in this thread "if the image is lazy decoded
and awsome is chosen then we do high quality resampling. Awsome is on by default
for all images on desktop. Awsome is off by default on android." I'm failing to
see how scaledimagecache is getting used on desktop today as lazy decode is
afaik only used with impl-side painting.

I guess it could be done by forcing lazy decoded or impl-side painting in
about:flags but that's not considered working until we enable this anyhow..

[reed1, 2013-12-12 20:29:54]

On 2013/12/12 20:26:13, David Reveman wrote:
> On 2013/12/12 19:53:23, reed1 wrote:
> > On 2013/12/12 19:34:33, David Reveman wrote:
> > > On 2013/12/12 19:20:09, reed1 wrote:
> > > > On 2013/12/12 16:32:56, David Reveman wrote:
> > > > > ping
> > > > 
> > > > Since you have identified bugs in the discardable version of
> > scaledimagecache,
> > > I
> > > > am presuming you don't want to enable it yet. Is that not the case?
> > > 
> > > I'm ok enabling this before that's fixed as we still need to turn on
> impl-side
> > > painting on a non-android platform for this to be used anywhere.
> > 
> > Hmmm, we see the scaledimagecache getting used today on desktops, so I'm not
> > sure we should enable a change to code that is known to have bugs. Help me
> > understand why it is better to enable this now.
> 
> Where are you seeing scaledimagecache getting used on desktop today? Local
> build?
> 
> Based on what Alpha said earlier in this thread "if the image is lazy decoded
> and awsome is chosen then we do high quality resampling. Awsome is on by
default
> for all images on desktop. Awsome is off by default on android." I'm failing
to
> see how scaledimagecache is getting used on desktop today as lazy decode is
> afaik only used with impl-side painting.
> 
> I guess it could be done by forcing lazy decoded or impl-side painting in
> about:flags but that's not considered working until we enable this anyhow..

If the paint asks for HQ filtering, and there is *any* scale in the matrix, then
we may use the cache. I don't think we have any 100% guarantee that that doesn't
happen today.

I would be more motivated to investigate that further if I knew the advantage of
switching to a buggy code-path right now...

[Alpha Left Google, 2013-12-12 20:30:09]

On 2013/12/12 20:26:13, David Reveman wrote:
> On 2013/12/12 19:53:23, reed1 wrote:
> > On 2013/12/12 19:34:33, David Reveman wrote:
> > > On 2013/12/12 19:20:09, reed1 wrote:
> > > > On 2013/12/12 16:32:56, David Reveman wrote:
> > > > > ping
> > > > 
> > > > Since you have identified bugs in the discardable version of
> > scaledimagecache,
> > > I
> > > > am presuming you don't want to enable it yet. Is that not the case?
> > > 
> > > I'm ok enabling this before that's fixed as we still need to turn on
> impl-side
> > > painting on a non-android platform for this to be used anywhere.
> > 
> > Hmmm, we see the scaledimagecache getting used today on desktops, so I'm not
> > sure we should enable a change to code that is known to have bugs. Help me
> > understand why it is better to enable this now.
> 
> Where are you seeing scaledimagecache getting used on desktop today? Local
> build?
> 
> Based on what Alpha said earlier in this thread "if the image is lazy decoded
> and awsome is chosen then we do high quality resampling. Awsome is on by
default
> for all images on desktop. Awsome is off by default on android." I'm failing
to
> see how scaledimagecache is getting used on desktop today as lazy decode is
> afaik only used with impl-side painting.
> 
> I guess it could be done by forcing lazy decoded or impl-side painting in
> about:flags but that's not considered working until we enable this anyhow..

Yes. Chrome needs --enable-impl-side-painting to use SkDiscardablePixelRef.
Unless with this change ScaledImageCache will be used even without
SkDiscardablePixelRef..

[reveman, 2013-12-19 23:46:59]

Latest patch disables the use of SkScaledImageCache unless deferred image
decoding is enabled on a non-Android platform.

This should remove any worries that enabling discardable memory for this cache
might accidentally affect configurations and platforms that it's not yet
intended for. PTAL.

[reveman, 2014-01-06 17:46:27]

ping for review

[reed1, 2014-01-06 18:04:40]

lgtm syntactically for the gypi change. I don't know the other file

[reveman, 2014-01-06 18:18:19]

+jamesr for content/renderer

[jamesr, 2014-01-07 21:34:28]

lgtm

[commit-bot: I haz the power, 2014-01-07 21:45:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/110863003/20001

[commit-bot: I haz the power, 2014-01-07 21:45:38]

Failed to apply patch for content/renderer/render_thread_impl.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file content/renderer/render_thread_impl.cc
  Hunk #2 FAILED at 94.
  Hunk #3 succeeded at 720 (offset -5 lines).
  1 out of 3 hunks FAILED -- saving rejects to file
content/renderer/render_thread_impl.cc.rej

Patch:       content/renderer/render_thread_impl.cc
Index: content/renderer/render_thread_impl.cc
diff --git a/content/renderer/render_thread_impl.cc
b/content/renderer/render_thread_impl.cc
index
9b85289a4eebde320e1ffa6cc5b209f0dda209ca..42903f28f8962bd5f2dd0c8bdc49d2c1ad78b46b
100644
--- a/content/renderer/render_thread_impl.cc
+++ b/content/renderer/render_thread_impl.cc
@@ -26,6 +26,7 @@
 #include "base/threading/thread_local.h"
 #include "base/threading/thread_restrictions.h"
 #include "base/values.h"
+#include "cc/base/switches.h"
 #include "content/child/appcache/appcache_dispatcher.h"
 #include "content/child/appcache/appcache_frontend_impl.h"
 #include "content/child/child_histogram_message_filter.h"
@@ -93,6 +94,7 @@
 #include "net/base/net_errors.h"
 #include "net/base/net_util.h"
 #include "third_party/skia/include/core/SkGraphics.h"
+#include "third_party/skia/src/core/SkScaledImageCache.h"
 #include "third_party/WebKit/public/platform/WebString.h"
 #include "third_party/WebKit/public/web/WebColorName.h"
 #include "third_party/WebKit/public/web/WebDatabase.h"
@@ -724,6 +726,19 @@ void RenderThreadImpl::EnsureWebKitInitialized() {
     ScheduleIdleHandler(kLongIdleHandlerDelayMs);
 
   webkit::SetSharedMemoryAllocationFunction(AllocateSharedMemoryFunction);
+
+  // Limit use of the scaled image cache to when deferred image decoding
+  // is enabled.
+  // TODO(reveman): Allow use of this cache on Android once
+  // SkDiscardablePixelRef is used for decoded images. crbug.com/330041
+  bool use_skia_scaled_image_cache = false;
+#if !defined(OS_ANDROID)
+  use_skia_scaled_image_cache =
+      command_line.HasSwitch(switches::kEnableDeferredImageDecoding) ||
+      cc::switches::IsImplSidePaintingEnabled();
+#endif
+  if (!use_skia_scaled_image_cache)
+    SkScaledImageCache::SetByteLimit(0u);
 }
 
 void RenderThreadImpl::RegisterSchemes() {

[commit-bot: I haz the power, 2014-01-07 21:58:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/110863003/110001

[commit-bot: I haz the power, 2014-01-07 23:13:02]

Retried try job too often on android_clang_dbg for step(s) slave_steps
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl...

[commit-bot: I haz the power, 2014-01-08 02:57:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/110863003/420001

[commit-bot: I haz the power, 2014-01-08 04:03:32]

Retried try job too often on win_rel for step(s) nacl_integration
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2014-01-08 05:35:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/110863003/420001

[commit-bot: I haz the power, 2014-01-08 08:12:38]

Retried try job too often on linux_chromeos for step(s) app_list_unittests,
ash_unittests, aura_unittests, base_unittests, browser_tests,
cacheinvalidation_unittests, check_deps, check_deps2git, chromeos_unittests,
components_unittests, content_browsertests, content_unittests, crypto_unittests,
dbus_unittests, device_unittests, events_unittests, google_apis_unittests,
gpu_unittests, interactive_ui_tests, ipc_tests, jingle_unittests,
media_unittests, net_unittests, ppapi_unittests, printing_unittests,
sandbox_linux_unittests, sql_unittests, sync_unit_tests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2014-01-08 16:28:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/110863003/420001

[commit-bot: I haz the power, 2014-01-08 17:37:47]

Change committed as 243592