| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the playback functionality out of SkPictureData. The old SkPictureData::draw method is pulled out along
with its supporting functions as verbatim as possible. Some follow on CLs will be required to:
re-enable profiling in the debugger (and remove the vestiges of SkTimedPicture)
re-enable display of command offsets in the picture (this should probably wait until we've switched to SkRecord though)
Clean up CachedOperationList (maybe fuse with SkPicture::OperationList)
Split SkPicturePlayback into a base class and two derived classes
Implement parallel version of GatherGPUInfo for SkRecord
Landing this is blocked on removing Android's use of the abortPlayback entry point.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/377623002
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for splitting the playback portion of the new SkPictureData class into a new SkPicturePlayback class.
R=reed@google.com, mtklein@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/362773002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
1) the atlased layers cannot be purged nor aged out
2) the texture backing the atlas is not pulled from (or returned to) the resource cache
#1 is on hold until we have a recycling rectanizer
A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
Committed: https://skia.googlesource.com/skia/+/55e61f0ef4e5c8c34ac107deaadc9b4ffef3111b
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354533004
|
|
|
|
|
|
|
|
|
|
| |
Remove the deprecated save(SaveFlags), willSave(SaveFlags) and all
traces of kMatrix_SaveFlags/kClip_SaveFlag.
BUG=skia:2297
R=mtklein@google.com, reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/340403003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reason for revert:
Sigh
Original issue's description:
> Begin atlasing
>
> This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
>
> 1) the atlased layers cannot be purged nor aged out
> 2) the texture backing the atlas is not pulled from (or returned to) the resource cache
>
> #1 is on hold until we have a recycling rectanizer
>
> A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
>
> Committed: https://skia.googlesource.com/skia/+/55e61f0ef4e5c8c34ac107deaadc9b4ffef3111b
R=bsalomon@google.com
TBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/359953002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
1) the atlased layers cannot be purged nor aged out
2) the texture backing the atlas is not pulled from (or returned to) the resource cache
#1 is on hold until we have a recycling rectanizer
A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354533004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrome will need -DSK_SUPPORT_LEGACY_PICTURE_CLONE.
This removes the modes from our tools that use clone(). No
bots run these. DM used clone() in a way that we can just
share the picture now.
I plan to bring back the ability to test multithreaded
picture rendering soon.
BUG=skia:2378
R=robertphillips@google.com, mtklein@google.com, bsalomon@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/338633011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- support fRecord in copy constructor
- support SkDrawPictureCallback
Moved SkDrawPictureCallback to its own header so
SkRecordDraw can include it without pulling in all of
SkPicture.
Adding an SkAutoSaveRestore to SkRecordDraw was the easiest
way to match the balance guarantees of the callback, and
probably not a bad idea in general. Updated its tests.
BUG=skia:
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/349973008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With new veto our new veto test results look like the following:
TP: true positive (picked to use gpu and gpu was faster)
I: inderminate, the raster time is withing 5% of gpu time
TP FP TN FN I
old 21 9 15 12 3
new 29 12 11 6 3
There are three skps that tend to move from TN -> FP, however
the absolute difference in their run times are not huge between
them. The largest being desk_booking which is about 7.1 raster
and 8.8 gpu. The other two skps are desk_yahooanswers and
desk_linkedin
BUG=skia:
R=bsalomon@google.com, robertphillips@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/334053005
|
|
|
|
|
|
|
|
|
|
| |
This CL simplifies the relationship between SkPicture and SkPicturePlayback by moving the path heap into SkPicturePlayback and removing SkPicturePlayback's SkPicture pointer.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/334493002
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL improves the separation of the SkPicture and SkPictureRecord classes. It delays creation of the SkPicture (in SkPictureRecorder) until recording is actually completed. To accomplish this the SkRecord-derived classes now get SkPathHeap and SkPictureContentInfo members that are absorbed by the SkPicture when it is constructed.
As an ancillary change, this CL also moves the SkPictureContentInfo object from SkPicture to SkPicturePlayback. This is intended to centralize all the data in the SkPicturePlayback object.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/324293004
|
|
|
|
|
|
|
|
|
|
| |
The issue is/was that the original Picture/PictureRecorder that is being partially replayed is not guaranteed to issue any more commands before attempting to modify the existing data. Such modification is prohibited if there is a extant copy-on-write snapshot. Rather then further complicate the SkWriter32::snapshot capability for a dis-preferred use case, this CL simply copies the operation data.
R=scroggo@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/316063005
|
|
|
|
|
|
|
|
|
|
| |
This is split out of https://codereview.chromium.org/316063005/ for clarity. Keeping in mind that SkPicture::FakeEndRecording is now only called from SkPictureRecorder, its deepCopy parameter is no longer necessary. This is b.c., given the new Picture recording semantics (where SkPictures can no longer be actively recording), cloning for thread safety only happens when an SkPicturePlayback has already been allocated (i.e., it happens in the SkPicturePlayback copy constructor.
R=scroggo@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/324093003
|
|
|
|
|
|
|
|
| |
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/313613004
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=mtklein@google.com, robertphillips@google.com
Author: reed@google.com
Review URL: https://codereview.chromium.org/291913004
git-svn-id: http://skia.googlecode.com/svn/trunk@14807 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This "fixes" the legacy interface's possible creation of pictures with unbalanced save/restores.
The Android dox will need to be updated once/if this lands.
R=reed@google.com, scroggo@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/286033005
git-svn-id: http://skia.googlecode.com/svn/trunk@14772 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL fixes 2 bugs in the pre-rendering of saveLayers:
1) The drawBitmapRect call wasn't occurring in device space so could sometimes be double transformed
2) The BBH op skipping in SkPicturePlayback could sometimes mess up the SkPictureStateTree's state
It also reduces the number of layers that are pre-rendered when a BBH is not in use.
Committed: http://code.google.com/p/skia/source/detail?r=14650
R=bsalomon@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/267293007
git-svn-id: http://skia.googlecode.com/svn/trunk@14659 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
| |
https://codereview.chromium.org/267293007) due to unit test failures
git-svn-id: http://skia.googlecode.com/svn/trunk@14654 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL fixes 2 bugs in the pre-rendering of saveLayers:
1) The drawBitmapRect call wasn't occurring in device space so could sometimes be double transformed
2) The BBH op skipping in SkPicturePlayback could sometimes mess up the SkPictureStateTree's state
It also reduces the number of layers that are pre-rendered when a BBH is not in use.
R=bsalomon@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/267293007
git-svn-id: http://skia.googlecode.com/svn/trunk@14650 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
| |
git-svn-id: http://skia.googlecode.com/svn/trunk@14636 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/261663003/
git-svn-id: http://skia.googlecode.com/svn/trunk@14632 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This refactoring seemed sufficiently fraught that I've broken it out of a larger patch to move fBitmapHeap out of SkPictureRecord/SkPicturePlayback and into SkPicture.
SkPicturePlayback's friending of SkPicture should be temporary and just allows SkPicture to access items that will be moving into it soon.
R=scroggo@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/256653006
git-svn-id: http://skia.googlecode.com/svn/trunk@14440 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation relies on soon-to-be-deprecated
kClip_SaveFlag behavior. Updated to use default save flags
(kMatrixClip_SaveFlag) and stop assuming that the matrix survives
restore() calls.
R=junov@chromium.org, reed@google.com, robertphillips@chromium.org, robertphillips@google.com
Committed: http://code.google.com/p/skia/source/detail?r=14319
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/246893005
git-svn-id: http://skia.googlecode.com/svn/trunk@14421 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kClip_SaveFlag. (https://codereview.chromium.org/246893005/)
Reason for revert:
https://code.google.com/p/chromium/issues/detail?id=366889
Original issue's description:
> Refactor SkPictureStateTree::Iterator to avoid use of kClip_SaveFlag.
>
> The current implementation relies on soon-to-be-deprecated
> kClip_SaveFlag behavior. Updated to use default save flags
> (kMatrixClip_SaveFlag) and stop assuming that the matrix survives
> restore() calls.
>
> R=junov@chromium.org,robertphillips@chromium.org,reed@google.com
>
> Committed: http://code.google.com/p/skia/source/detail?r=14319
R=junov@chromium.org, reed@google.com, robertphillips@chromium.org, robertphillips@google.com, fmalita@chromium.org
TBR=fmalita@chromium.org, junov@chromium.org, reed@google.com, robertphillips@chromium.org, robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
Author: bsalomon@google.com
Review URL: https://codereview.chromium.org/250733007
git-svn-id: http://skia.googlecode.com/svn/trunk@14383 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
| |
git-svn-id: http://skia.googlecode.com/svn/trunk@14346 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL begins the process of making SkPicturePlayback & SkPictureRecord independent of SkPicture. It just moves the PathHeap into SkPicture to get a feel for where all this is going to lead.
Some items of note:
SkTimedPicture (debugger/QT) should wind up being just an SkPicturePlayback-derived object.
All the flattening & unflattening should migrate out of SkPicturePlayback and into SkPicture.
SkPicture::initForPlayback should eventually become something just SkPictureRecorder::endRecording calls.
SkPicture is passed into SkPicturePlayback's & SkPictureRecord's constructors. SkPicturePlayback only
holds onto a "const SkPicture*". The SkPicturePlayback:: CreateFromStream & CreateFromBuffer methods pass a non-const
SkPicture* down the call stack.
BUG=skia:2315
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/249453002
git-svn-id: http://skia.googlecode.com/svn/trunk@14341 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation relies on soon-to-be-deprecated
kClip_SaveFlag behavior. Updated to use default save flags
(kMatrixClip_SaveFlag) and stop assuming that the matrix survives
restore() calls.
R=junov@chromium.org, reed@google.com, robertphillips@chromium.org, robertphillips@google.com
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/246893005
git-svn-id: http://skia.googlecode.com/svn/trunk@14319 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=robertphillips@google.com
Author: reed@google.com
Review URL: https://codereview.chromium.org/244273002
git-svn-id: http://skia.googlecode.com/svn/trunk@14302 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix warnings around undeclared (non-static) functions
TBR=bsalomon@google.com
Author: reed@google.com
Review URL: https://codereview.chromium.org/242643008
git-svn-id: http://skia.googlecode.com/svn/trunk@14267 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code is currently unused and is contrary to the way in which we seem to be moving towards accomplishing this (i.e., device-specific optimization passes).
This is a partial revert of r13704 (First version of bitmap use tracking in SkPictureRecord - https://codereview.chromium.org/187833003/)
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/237013002
git-svn-id: http://skia.googlecode.com/svn/trunk@14179 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is from an earlier iteration of the pull-forward task before we switched to doing the majority of the work in SkGpuDevice.
R=jvanverth@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/235473002
git-svn-id: http://skia.googlecode.com/svn/trunk@14162 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=scroggo@google.com, dominikg@chromium.org
Author: reed@google.com
Review URL: https://codereview.chromium.org/233753002
git-svn-id: http://skia.googlecode.com/svn/trunk@14142 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will let code outside SkPicture* fork its read code based on the picture version.
BUG=skia:
R=reed@google.com, robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/214413008
git-svn-id: http://skia.googlecode.com/svn/trunk@13984 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
| |
When gathering information about a picture (in the new SkDevice::EXPERIMENTAL_optimize entry point) it is necessary to be able to correlate the gathered information with the command in the SkPicture (so the information can later be combined with the similarly indexed information from the BBH). This entry point exposes that information to friend classes.
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/206853003
git-svn-id: http://skia.googlecode.com/svn/trunk@13919 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
| |
git-svn-id: http://skia.googlecode.com/svn/trunk@13855 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the "pull forward" task I will be comparing the two cases:
analyze the whole skp and use the BBH information
analyze only the active portion of the skp
In the first case we need a way to get the BBH information out of the picture in order to extract the relevant portions of the whole-skp analysis. This adds caching of the active ops so that work isn't duplicated between when the optimization path queries for that information and when the usual draw path queries for it.
Committed: http://code.google.com/p/skia/source/detail?r=13836
R=reed@google.com, bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/195793010
git-svn-id: http://skia.googlecode.com/svn/trunk@13853 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/203333005/
git-svn-id: http://skia.googlecode.com/svn/trunk@13850 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
| |
git-svn-id: http://skia.googlecode.com/svn/trunk@13845 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the "pull forward" task I will be comparing the two cases:
analyze the whole skp and use the BBH information
analyze only the active portion of the skp
In the first case we need a way to get the BBH information out of the picture in order to extract the relevant portions of the whole-skp analysis. This adds caching of the active ops so that work isn't duplicated between when the optimization path queries for that information and when the usual draw path queries for it.
R=reed@google.com, bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/195793010
git-svn-id: http://skia.googlecode.com/svn/trunk@13836 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
| |
SkPicture) due to Mac compiler issue
git-svn-id: http://skia.googlecode.com/svn/trunk@13832 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/195793010/
git-svn-id: http://skia.googlecode.com/svn/trunk@13831 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new way of implementing https://codereview.chromium.org/155863005/
It uses copy on write semantics to return a buffer without copying it, so that record -> playback does not need to copy the buffer.
BUG=skia:2125
R=tomhudson@google.com, mtklein@google.com, reed@google.com, iancottrell@chromium.org
Author: iancottrell@google.com
Review URL: https://codereview.chromium.org/167113003
git-svn-id: http://skia.googlecode.com/svn/trunk@13769 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
| |
R=jvanverth@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/192783002
git-svn-id: http://skia.googlecode.com/svn/trunk@13724 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Future enhancements will:
track the portion of the bitmap required
track any resizing that might be required
actually preload something
R=bsalomon@google.com, mtklein@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/187833003
git-svn-id: http://skia.googlecode.com/svn/trunk@13704 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
| |
R=mtklein@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/182153003
git-svn-id: http://skia.googlecode.com/svn/trunk@13692 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
| |
better. The main concern is that the assumptions made w.r.t. written bytes may not be valid for all SkWStream sub-classes.
R=bungeman@gmail.com, bungeman@google.com, reed@google.com, mtklein@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/182733008
git-svn-id: http://skia.googlecode.com/svn/trunk@13673 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intended to help automate weeding these out.
Please see skbug:1057
rmistry for tools, gyp
mtklein for src\core & include\core
BUG=skia:1057
R=rmistry@google.com, mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/176863004
git-svn-id: http://skia.googlecode.com/svn/trunk@13643 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/183453002/
git-svn-id: http://skia.googlecode.com/svn/trunk@13627 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
| |
https://codereview.chromium.org/183453002/) due to broken Chrome Canary and failing tests.
git-svn-id: http://skia.googlecode.com/svn/trunk@13622 2bbb7eff-a529-9590-31e7-b0007b416f81
|