aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkPicturePlayback.h
Commit message (Collapse)AuthorAge
* Propagate validation errors from inner readbuffer when deserializing ↵Gravatar reed2016-09-30
| | | | | | | | | picture. Also allow null paints. BUG=skia:5812 GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2379383002 Review-Url: https://codereview.chromium.org/2379383002
* Optionally enable SkValidatingReadBuffer in SkPictureImageFilterGravatar robertphillips2016-04-22
| | | | | | | | | | The task here is to get the type of ReadBuffer being used in SkPicture::MakeFromBuffer mirrored in the down-stack SkPicturePlayback::draw call. BUG=skia:5208 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1918433002 Review URL: https://codereview.chromium.org/1918433002
* Fix ImageFilter fuzzer issueGravatar robertphillips2016-04-20
| | | | | | | | | What appears to be happening in this fuzz is that a paint index inside the picture of an SkPictureImageFilter is getting changed to be out of range. BUG=skia:5192 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1893423002 Review URL: https://codereview.chromium.org/1893423002
* Rename SkDrawPictureCallback to SkPicture::AbortCallbackGravatar robertphillips2015-01-07
| | | | | | Committed: https://skia.googlesource.com/skia/+/7ef197255deb4e2fa64c03c7130d56ddf164e83c Review URL: https://codereview.chromium.org/829983003
* Revert of Rename SkDrawPictureCallback to SkPicture::AbortCallback (patchset ↵Gravatar reed2015-01-06
| | | | | | | | | | | | | | | | | | #2 id:20001 of https://codereview.chromium.org/829983003/) Reason for revert: speculative revert to unblock DEPS roll Original issue's description: > Rename SkDrawPictureCallback to SkPicture::AbortCallback > > Committed: https://skia.googlesource.com/skia/+/7ef197255deb4e2fa64c03c7130d56ddf164e83c TBR=reed@google.com,robertphillips@google.com NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/824013004
* Rename SkDrawPictureCallback to SkPicture::AbortCallbackGravatar robertphillips2015-01-06
| | | | Review URL: https://codereview.chromium.org/829983003
* More SkPicture cleanupGravatar mtklein2014-11-17
| | | | | | | | | | | | | | | | - move field declarations together and pack them a little tighter - get rid of fData - remove dead code in debugger, including unused SkPicturePlayback subclass There are now no more long-lived SkPictureData! (Really, there never were, but now we don't pretend to support them.) BUG=skia: No API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/725143002
* Strip old backend recording down to essentialsGravatar mtklein2014-09-30
| | | | | | | | | | | | | | | | | | | | | | | | | Feature-wise, this removes: 1) BBH support; 2) peephole optimizations; 3) record-time text op specializations; 4) the guarantee that SkPaints are flattened. This deletes the optimizations GM, which only exists to test the peepholes of the old backend. SkRecord optimizations are unit tested, and if that ever fails we can think about adding another GM like this, but they're different enough we'd want to start from scratch anyway. We need to keep the code that plays back the specialized text ops around for a while for compatibility with existing .SKPs that have those ops recorded. BUG=skia: CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot R=robertphillips@google.com, reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/617953002
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* Split SkPictureReplacementPlayback out of SkPicturePlaybackGravatar robertphillips2014-07-10
| | | | | | | | R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/383733002
* Refactor SkPicturePlayback for SkPictureReplacementPlaybackGravatar robertphillips2014-07-09
| | | | | | | | | | This CL is intended to maximize code reuse when SkPictureReplacementPlayback is split off. R=mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/378343002
* Fixed up SkTimedPicturePlaybackGravatar robertphillips2014-07-08
| | | | | | | | | | This was more motivated to remove the preDraw and postDraw virtuals from SkPicturePlayback. R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/375943002
* Split SkPictureRangePlayback out of SkPicturePlaybackGravatar robertphillips2014-07-08
| | | | | | | | | | | | | This CL starts cleaning up SkPicturePlayback. Future CLs will: split out the SkPictureReplacementPlayback remove the preDraw/postDraw entry points & fix up SkPictureTimedPlayback R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/374833006
* Clean up a bit after SkPictureData/SkPicturePlayback splitGravatar robertphillips2014-07-08
| | | | | | | | | | | | | This CL begins setting up the SkPicturePlayback split by simplifying the class and componentizing it a bit. It: fuses SkPictureData::OperationList into SkPicture::OperationList adds a handleOp method to SkPicturePlayback that can be reused by derived classes removes a couple debugging tools (ENABLE_TIME_DRAW & SPEW_CLIP_SKIPPING) R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/378703002
* Split SkPicturePlayback out of SkPictureDataGravatar robertphillips2014-07-07
| | | | | | | | | | | | | | | | | | | 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
* Rename SkPicturePlayback to SkPictureDataGravatar robertphillips2014-07-01
| | | | | | | | | | 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
* Begin atlasingGravatar robertphillips2014-06-30
| | | | | | | | | | | | | | | | | | | 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
* Revert of Begin atlasing (https://codereview.chromium.org/354533004/)Gravatar robertphillips2014-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Begin atlasingGravatar robertphillips2014-06-29
| | | | | | | | | | | | | | | | | 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
* Deprecate SkPicture::clone().Gravatar mtklein2014-06-27
| | | | | | | | | | | | | | | | | | 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
* Move allocation of texture from SkGpuDevice to GrLayerCacheGravatar robertphillips2014-06-24
| | | | | | | | | | In order to atlas the layers the GrLayerCache needs to be given more control over where a given layer's texture is allocated (i.e., it could be a raw scratch texture or in the cache). R=bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/350183006
* Remove dashing from gpu vetoGravatar egdaniel2014-06-18
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove SkPicture pointer from SkPicturePlaybackGravatar robertphillips2014-06-12
| | | | | | | | | | 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
* Remove picture pre-allocation from SkPictureRecorderGravatar robertphillips2014-06-11
| | | | | | | | | | | | 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
* Fix error revealed by Android unit testGravatar robertphillips2014-06-10
| | | | | | | | | | 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
* Remove unused 'deepCopy' parameterGravatar robertphillips2014-06-10
| | | | | | | | | | 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
* Alter SkCanvas::drawPicture (devirtualize, take const SkPicture, take pointer)Gravatar robertphillips2014-06-04
| | | | | | | | R=reed@google.com, bsalomon@google.com, mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/313613004
* Fix rendering artifacts in pull-saveLayers-forward modeGravatar commit-bot@chromium.org2014-05-08
| | | | | | | | | | | | | | | | | | | | 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
* Revert r14650 (Fix rendering artifacts in pull-saveLayers-forward mode - ↵Gravatar robertphillips@google.com2014-05-08
| | | | | | 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
* Fix rendering artifacts in pull-saveLayers-forward modeGravatar commit-bot@chromium.org2014-05-08
| | | | | | | | | | | | | | | | | | 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
* Sanitizing source files in Housekeeper-NightlyGravatar skia.committer@gmail.com2014-05-08
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@14636 2bbb7eff-a529-9590-31e7-b0007b416f81
* First pass at pre-rendering saveLayers for GPUGravatar robertphillips@google.com2014-05-07
| | | | | | | | https://codereview.chromium.org/261663003/ git-svn-id: http://skia.googlecode.com/svn/trunk@14632 2bbb7eff-a529-9590-31e7-b0007b416f81
* Move setup of SkPictCopyInfo into SkPicture::cloneGravatar commit-bot@chromium.org2014-04-29
| | | | | | | | | | | | | | 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
* Sanitizing source files in Housekeeper-NightlyGravatar skia.committer@gmail.com2014-04-24
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@14346 2bbb7eff-a529-9590-31e7-b0007b416f81
* First step in pulling SkPicturePlayback & SkPictureRecord out of SkPictureGravatar commit-bot@chromium.org2014-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix size_t/int warnings in picturesGravatar commit-bot@chromium.org2014-04-22
| | | | | | | | | | | 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
* Remove currently unused codeGravatar commit-bot@chromium.org2014-04-14
| | | | | | | | | | | | | | 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
* remove dead code from SkPicturePlaybackGravatar commit-bot@chromium.org2014-04-11
| | | | | | | | | | | | 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
* Thread picture version through to SkReadBuffer.Gravatar commit-bot@chromium.org2014-03-28
| | | | | | | | | | | | | 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
* Add new experimental API to SkPicture to get "id" of current opGravatar commit-bot@chromium.org2014-03-24
| | | | | | | | | | | | 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
* Add a means of extracting active operations from SkPictureGravatar commit-bot@chromium.org2014-03-18
| | | | | | | | | | | | | | | | | | 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
* Revert of r13836 due to Chromium cc_unittests failuresGravatar robertphillips@google.com2014-03-18
| | | | | | | | https://codereview.chromium.org/203333005/ git-svn-id: http://skia.googlecode.com/svn/trunk@13850 2bbb7eff-a529-9590-31e7-b0007b416f81
* Add a means of extracting active operations from SkPictureGravatar commit-bot@chromium.org2014-03-17
| | | | | | | | | | | | | | | | 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
* Reverting r13831 (Add a means of extracting active operations from ↵Gravatar robertphillips@google.com2014-03-17
| | | | | | SkPicture) due to Mac compiler issue git-svn-id: http://skia.googlecode.com/svn/trunk@13832 2bbb7eff-a529-9590-31e7-b0007b416f81
* Add a means of extracting active operations from SkPictureGravatar robertphillips@google.com2014-03-17
| | | | | | | | https://codereview.chromium.org/195793010/ git-svn-id: http://skia.googlecode.com/svn/trunk@13831 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fixing SkPicture serializationGravatar commit-bot@chromium.org2014-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* This is just the first version and shows how I intend to orchestrate this. ↵Gravatar commit-bot@chromium.org2014-03-07
| | | | | | | | | | | | | | | | 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
* Generating the 1M skps frequently yields truncated skps. This tool is ↵Gravatar commit-bot@chromium.org2014-03-03
| | | | | | | | | | | | | | | | | | 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
* Revert of Revert "Serialization of SkPictureImageFilter" ↵Gravatar commit-bot@chromium.org2014-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/153583007/) Reason for revert: New SKPs with version20 are in Google Storage due to http://108.170.219.160:10117/builders/Housekeeper-Nightly-RecreateSKPs/builds/22 Original issue's description: > Revert "Serialization of SkPictureImageFilter" > > This reverts commit 227321b30106e57942929eb96fa5bc22544f6c9e. > > Revert "Sanitizing source files in Housekeeper-Nightly" > > This reverts commit baf28584b7636c01355f8d8d972e06aa7fb66d77. > > TBR=robertphillips@google.com,sugoi@google.com > > Committed: https://code.google.com/p/skia/source/detail?r=13356 R=robertphillips@google.com, sugoi@google.com, fmalita@google.com, fmalita@chromium.org TBR=fmalita@chromium.org, fmalita@google.com, robertphillips@google.com, sugoi@google.com NOTREECHECKS=true NOTRY=true Author: rmistry@google.com Review URL: https://codereview.chromium.org/143163005 git-svn-id: http://skia.googlecode.com/svn/trunk@13357 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert "Serialization of SkPictureImageFilter"Gravatar fmalita@google.com2014-02-07
| | | | | | | | | | | | | | This reverts commit 227321b30106e57942929eb96fa5bc22544f6c9e. Revert "Sanitizing source files in Housekeeper-Nightly" This reverts commit baf28584b7636c01355f8d8d972e06aa7fb66d77. TBR=robertphillips@google.com,sugoi@google.com Review URL: https://codereview.chromium.org/153583007 git-svn-id: http://skia.googlecode.com/svn/trunk@13356 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-28 02:19:41 +0000