aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkPictureRecorder.cpp
Commit message (Collapse)AuthorAge
* Install a hook to swap between SkPicture backends with a single define.Gravatar mtklein2014-08-21
| | | | | | | | | BUG=skia: R=robertphillips@google.com, reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/492023002
* Plumbing for using a BBH in SkRecordDraw.Gravatar mtklein2014-08-11
| | | | | | | | | | | | | | | | For now this only creates a degenerate bounding box hierarchy where all ops just have maximal bounds. I will flesh out FillBounds in future CL(s). Not quite sure why QuadTree and TileGrid aren't drawing right---haven't even looked at the diffs yet---so I've disabled those test modes for now. RTree seems fine, so that'll at least get us coverage for all this new plumbing. BUG=skia: R=robertphillips@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/454123003
* 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
* Enable basic drawing with SkRecord-based pictures.Gravatar Mike Klein2014-06-23
| | | | | | | | | | | | | | | | | I've tagged all the functions in SkPicture.cpp is // fRecord TODO or // fRecord OK, depending on whether or not they're totally broken when used from an SkRecord-based picture. Obviously next steps are to eliminate all the TODOs, then clean up the notes. I converted SkPicture over to smart pointers too. It's particularly helpful that the smart pointers initialize to NULL by default. For now I've got all the SkRecord-based code jammed in at the bottom of the file. I figure it'll help me keep things straight for a bit, then we can rearrange later. BUG=skia: R=robertphillips@google.com Review URL: https://codereview.chromium.org/333823007
* Use smart pointers to make SkPictureRecorder lifetimes less manual.Gravatar Mike Klein2014-06-23
| | | | | | | BUG=skia: R=robertphillips@google.com Review URL: https://codereview.chromium.org/344253005
* Add EXPERIMENTAL_beginRecording() for SkRecord-based recording.Gravatar mtklein2014-06-17
| | | | | | | | | | | | | The interesting stuff is in SkPictureRecorder.{h,cpp}. The rest is mostly moving SkRecord from its own directories into core to avoid circular dependencies in GYP. After plumbing SkRecord all the way through in Picture, I'll delete its old entry point include/record/SkRecording.h. For now it and record.gypi need to stay where they are to keep Chrome building. BUG=skia: R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/331573004
* 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
* No longer limit SkPictureRecorder::partialReplay to AndroidGravatar robertphillips2014-06-08
| | | | | | | | | | Toggling this for local testing is a bit of a chore. R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/316173004
* First pass at splitting out SkPictureRecord from SkPictureGravatar robertphillips2014-06-08
| | | | | | | | | | | | This patch begins the process of splitting apart SkPicture, SkPicturePlayback and SkPictureRecord. This is still a bit messy. In a follow up CL I hope to delay the creation of SkPictureRecorder's SkPicture until endRecording time. R=reed@google.com, mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/318763004
* Make SkPictureRecorder::partialReplay constGravatar commit-bot@chromium.org2014-05-29
| | | | | | | | | | | | This will make it easier to integrate this into Android's use case. R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/307693003 git-svn-id: http://skia.googlecode.com/svn/trunk@14957 2bbb7eff-a529-9590-31e7-b0007b416f81
* Include SkTypes to fix Android frameworks buildGravatar commit-bot@chromium.org2014-05-28
| | | | | | | | | | | | | | | | | Since Android's defines are included in SkUserConfig (rather than being defined in the build file), we need to include something that includes SkUserConfig (transitively; meaning just about anything) before we can use any build macros. Include SkTypes, "the correct way to get access to the config system" so that SK_BUILD_FOR_ANDROID is defined before querying it. R=robertphillips@google.com, djsollen@google.com, mtklein@google.com Author: scroggo@google.com Review URL: https://codereview.chromium.org/294393011 git-svn-id: http://skia.googlecode.com/svn/trunk@14914 2bbb7eff-a529-9590-31e7-b0007b416f81
* add replay entry point to SkPictureRecorder for AndroidGravatar commit-bot@chromium.org2014-05-27
| | | | | | | | | | | | This CL adds an Android-only entry point to address the Java Picture(Picture) and serialize use cases. Note that (in its current form) it doesn't preserve the old API's handling of unbalanced saves/saveLayers (this CL always balances them). R=reed@google.com, scroggo@google.com, djsollen@google.com, mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/252873005 git-svn-id: http://skia.googlecode.com/svn/trunk@14911 2bbb7eff-a529-9590-31e7-b0007b416f81
* Staging for cleanup of SkPicture-related headersGravatar robertphillips@google.com2014-04-18
https://codereview.chromium.org/243173002 git-svn-id: http://skia.googlecode.com/svn/trunk@14258 2bbb7eff-a529-9590-31e7-b0007b416f81