aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkPicturePlayback.cpp
Commit message (Collapse)AuthorAge
...
* 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
* SaveFlags be-goneGravatar Florin Malita2014-06-30
| | | | | | | | | | 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
* 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
* Tick off some TODOs:Gravatar Mike Klein2014-06-24
| | | | | | | | | | | | | | | | | | - 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
* 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
* formalize named picture versionsGravatar commit-bot@chromium.org2014-05-20
| | | | | | | | | | | 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
* Ensure playing back a picture always balances saves and restoresGravatar commit-bot@chromium.org2014-05-19
| | | | | | | | | | | | | | 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
* 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
* Refactor SkPictureStateTree::Iterator to avoid use of kClip_SaveFlag.Gravatar commit-bot@chromium.org2014-04-28
| | | | | | | | | | | | | | | | | 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
* Revert of Refactor SkPictureStateTree::Iterator to avoid use of ↵Gravatar commit-bot@chromium.org2014-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Refactor SkPictureStateTree::Iterator to avoid use of kClip_SaveFlag.Gravatar commit-bot@chromium.org2014-04-23
| | | | | | | | | | | | | | | 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
* 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
* fix warnings around size_t/intGravatar commit-bot@chromium.org2014-04-19
| | | | | | | | | | | | 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
* 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
* remove two more effects that are now immutableGravatar commit-bot@chromium.org2014-04-10
| | | | | | | | | | | 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
* 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
* Sanitizing source files in Housekeeper-NightlyGravatar skia.committer@gmail.com2014-03-19
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@13855 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
* Sanitizing source files in Housekeeper-NightlyGravatar skia.committer@gmail.com2014-03-18
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@13845 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
* Add capture snapshot as data to SkWriter32, use it to optimise record->playback.Gravatar commit-bot@chromium.org2014-03-12
| | | | | | | | | | | | | | 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
* 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
* Pulling these out of other reviews so avoid code review clutter.Gravatar commit-bot@chromium.org2014-03-10
| | | | | | | | | | 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
* 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
* Add debug check of chunk size written to skpGravatar commit-bot@chromium.org2014-03-06
| | | | | | | | | | 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
* This CL is motivated by the desire to make the skpinfo tool work a bit ↵Gravatar commit-bot@chromium.org2014-03-05
| | | | | | | | | | | | 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
* 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
* add new onClip* methods to SkCanvasGravatar robertphillips@google.com2014-02-28
| | | | | | | | https://codereview.chromium.org/183453002/ git-svn-id: http://skia.googlecode.com/svn/trunk@13627 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert of r13620 (add new onClip* methods to SkCanvas - ↵Gravatar robertphillips@google.com2014-02-28
| | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-30 15:57:07 +0000