aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkPicture.cpp
Commit message (Collapse)AuthorAge
...
* Shrink saveLayer device bounds when it supplies an explicit bounds and has a ↵Gravatar robertphillips2014-11-03
| | | | | | | | | | | | | | | | | | | | | | complex paint This CL shrinks the bound computed for saveLayers that possess both an explicit bound and a complex paint (e.g., one that affects transparent black). In this case the bound of the layer should be the clipped explicit bound rather then the clip prior/after the saveLayer/restore block. In the following the first bound is the currently computed bound while the second is the new/desired one: For a 100x100 picture saveLayer (no bound, no paint) [ 0 0 100 100 ] [ 50 50 100 100 ] setMatrix (translate 50, 50) [ 0 0 100 100 ] [ 50 50 100 100 ] saveLayer (bound of 0, 0, 50, 50 - complex paint) [ 0 0 100 100 ] [ 50 50 100 100 ] restore [ 0 0 100 100 ] [ 50 50 100 100 ] restore [ 0 0 100 100 ] [ 50 50 100 100 ] Review URL: https://codereview.chromium.org/696763002
* Remove DEPRECATED_beginRecording().Gravatar mtklein2014-10-01
| | | | | | | | | | | | | | | This removes: 1) ability to record old pictures with SkPictureRecorder; 2) a couple tests specific to the old backend. The functionality of DEPRECATED_beginRecording() now lives in (private) SkPicture::Backport(), which is the only place we need it now. BUG=skia: TBR=reed@google.com Review URL: https://codereview.chromium.org/618303002
* 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
* Clean up SK_PICTURE_USE_SK_RECORD and SK_PICTURE_OPTIMIZE_SK_RECORD.Gravatar mtklein2014-09-30
| | | | | | | | | | | | | | | | | This folds the code through as if they were defined, which is the explicit state in both our build and Chrome's. This leaves the EXPERIMENTAL_ and DEPRECATED_ hooks in to be cleaned up or privatized later. CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot BUG=skia: R=reed@google.com, robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/616033002
* Remove support for SkPicture::clone().Gravatar mtklein2014-09-30
| | | | | | | | | | | | | | | | This folds SK_SUPPORT_LEGACY_PICTURE_CLONE through as undefined. Chrome's not used clone() for a month or two, and we don't use it ourselves. Don't think Android ever did. CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot BUG=skia: R=reed@google.com, mtklein@google.com, robertphillips@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/620533002
* SkPicture::PathCounter is O(N^2) for pictures nested N deep. Fix that.Gravatar mtklein2014-09-15
| | | | | | | | | | | We've already done the analysis for child pictures. Don't do it again. BUG=skia: R=fmalita@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/573833002
* Add flag to call SkRecordOptimize on new pictures.Gravatar mtklein2014-09-15
| | | | | | | | | | | As usual it's enabled by default in the Skia tree. Will flip in Chrome after this rolls. BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/573773002
* Delay any SkRecordOptimize until after SkRecord has stuck.Gravatar mtklein2014-09-10
| | | | | | | | | BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/561993002
* Turn on the save-layer optimization.Gravatar mtklein2014-09-08
| | | | | | | | | BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/551853002
* Turn on all pixel-perfect SkRecord optimizations.Gravatar mtklein2014-09-08
| | | | | | | | | BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/550083006
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* Change SkPicture::draw to playbackGravatar robertphillips2014-09-04
| | | | | | | | R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/540963002
* Remove use of EXPERIMENTAL_getActiveOps from layer hoisting codeGravatar robertphillips2014-09-03
| | | | | | | | | | This is getting in the way of switching to the SkRecord backend and is of questionable value. R=bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/539693002
* Remove legacy (and also broken) SkPicture constructor.Gravatar djsollen2014-09-02
| | | | | | | | R=robertphillips@google.com, reed@google.com Author: djsollen@google.com Review URL: https://codereview.chromium.org/532703004
* Try out scalar picture sizesGravatar robertphillips2014-08-29
| | | | | | | | | | This paves the way for removing the 'fTile' parameter from SkPictureShader (although that should be a different CL). If we like this we could also move to providing an entire cull SkRect. R=reed@google.com, mtklein@google.com, fmalita@google.com, fmalita@chromium.org Author: robertphillips@google.com Review URL: https://codereview.chromium.org/513983002
* Convert BBH APIs to use SkRect.Gravatar mtklein2014-08-27
| | | | | | | | | | | | | Still TODO: convert internals of SkTileGrid.cpp and SkRTree.cpp to work in floats too. NOTREECHECKS=true BUG=skia:1021 R=robertphillips@google.com, reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/511613002
* Revert of Revert back to SkPictureData pictures. Huge perf regression. ↵Gravatar mtklein2014-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #1 of https://codereview.chromium.org/496603002/) Reason for revert: Try again now that we have --bbh on nanobench and it's looking decent. Original issue's description: > Revert back to SkPictureData pictures. Huge perf regression. > > http://skiaperf.com/#108 > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/4082d290eea2f70caa82120ff3bc4fbdccbf206c R=reed@google.com, mtklein@chromium.org TBR=mtklein@chromium.org, reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Author: mtklein@google.com Review URL: https://codereview.chromium.org/496173002
* 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
* Our SkPicture::Analysis visitors should recurse into nested pictures.Gravatar mtklein2014-08-21
| | | | | | | | | BUG=skia: R=tomhudson@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/495793002
* Revert back to SkPictureData pictures. Huge perf regression.Gravatar mtklein2014-08-20
| | | | | | | | | | | http://skiaperf.com/#108 BUG=skia: R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/496603002
* Always read .skp files and other serialized pictures into SkRecord.Gravatar mtklein2014-08-20
| | | | | | | | | | | | | | | | This should switch all our internal tools that aren't clever about it over to SkRecord pictures. (The clever tools know what they're doing.) Also, deletes the old SkPicture::clone() path. return this or die. BUG=skia: Committed: https://skia.googlesource.com/skia/+/7b705bb17e09508e3761b54f59833b1ceb4ce9a6 R=robertphillips@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/481743003
* Always read .skp files and other serialized pictures into SkRecord.Gravatar mtklein2014-08-20
| | | | | | | | | | | | | This should switch all our internal tools that aren't clever about it over to SkRecord pictures. (The clever tools know what they're doing.) Also, deletes the old SkPicture::clone() path. return this or die. BUG=skia: R=robertphillips@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/481743003
* Implement SkPicture::hasText() for SkRecord backend.Gravatar mtklein2014-08-20
| | | | | | | | | | | | Plus, some small tweaks to the existing code surrounding it. Just proposals, will undo whatever you don't like. BUG=skia: R=mtklein@google.com, tomhudson@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/494683003
* Move the code over using the same template type approach previously used for ↵Gravatar tomhudson2014-08-20
| | | | | | | | | | | | | | | willPlayBackBitmaps in http://skbug.com/2702. Also unifies that flag and this one into a struct so they and others can be computed together. The struct is stored const to enforce lifetime expectations. Adds a few new cases to the unit test. BUG=skia:2700 R=mtklein@google.com, reed@google.com, robertphillips@google.com, tomhudson@google.com Committed: https://skia.googlesource.com/skia/+/60c2a79cfa8ceebcbafc243407564dc71f5e3b4f Author: tomhudson@chromium.org Review URL: https://codereview.chromium.org/364823009
* Revert "Move the code over using the same template type approach previously ↵Gravatar Mike Klein2014-08-18
| | | | | | | | | | used for willPlayBackBitmaps in http://skbug.com/2702." This reverts commit 60c2a79cfa8ceebcbafc243407564dc71f5e3b4f. BUG=skia: Review URL: https://codereview.chromium.org/481173003
* Move the code over using the same template type approach previously used for ↵Gravatar tomhudson2014-08-18
| | | | | | | | | | | | | willPlayBackBitmaps in http://skbug.com/2702. Also unifies that flag and this one into a struct so they and others can be computed together. The struct is stored const to enforce lifetime expectations. Adds a few new cases to the unit test. BUG=skia:2700 R=mtklein@google.com, reed@google.com, robertphillips@google.com, tomhudson@google.com Author: tomhudson@chromium.org Review URL: https://codereview.chromium.org/364823009
* Counterproposal for skirting the BBH when the query fully contains the picture.Gravatar mtklein2014-08-18
| | | | | | | | | BUG=skia: R=reed@google.com, robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/485703002
* Expose API for whether an SkPicture contains textGravatar ajuma2014-08-18
| | | | | | | | | BUG=chromium:399728 R=reed@google.com, nduca@chromium.org Author: ajuma@chromium.org Review URL: https://codereview.chromium.org/478673002
* int SkPicture::approximateOpCount()Gravatar mtklein2014-08-14
| | | | | | | | | | | NOTREECHECKS=true BUG=skia: R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/470333002
* Cleaning up SkPicture-related classesGravatar robertphillips2014-08-11
| | | | | | | | R=mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/459043002
* 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
* SkPicture: try to no-op away clone().Gravatar mtklein2014-08-06
| | | | | | | | | | | Will actually enable this by #defining SK_PICTURE_CLONE_NOOP in Chrome's SkUserConfig.h as a separate CL after this rolls in. BUG=skia: R=reed@google.com, robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/447753003
* Add auto purging for SkPicture-related Ganesh resources (esp. layers)Gravatar robertphillips2014-07-22
| | | | | | | | | | This is intended to lower the bookkeeping burden for the Layer Caching feature. Cached layers are now automatically purged when a picture is deleted. R=bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/408923002
* Remove Skia's use of the default SkPicture constructor and multi-cloneGravatar Robert Phillips2014-07-13
| | | | | | | | | This cannot be landed until (Chrome: Switch to one-at-a-time SkPicture::clone interface - https://codereview.chromium.org/380323002/) has landed. R=mtklein@google.com TBR=reed@google.com Review URL: https://codereview.chromium.org/388833003
* Remove SkPicture copy constructorGravatar robertphillips2014-07-13
| | | | | | | | | | Given where we're heading with SkPicture why would you need to make a copy? R=reed@google.com, mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/381133002
* Revert of Add alternate SkPicture::clone ↵Gravatar robertphillips2014-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/381193002/) Reason for revert: Going to try to just remove the many-at-once clone interface Original issue's description: > Add alternate SkPicture::clone > > This adds an alternate version of SkPicture::clone for two reasons: > > 1) Chromium uses the SkPicture copy constructor to unpack the pictures from the old-style clone interface (and I would like to remove the copy ctor) > > 2) This is part of the long term plan to wean Chrome off of cloning. Once pictures are thread safe we will switch the new SkPicture::clone call to just return 'this'. From there it is a small step to removing clone entirely. > > Note that the two versions of clone() is temporary. Once this is landed (and rolled) I will land a Chrome-side patch to remove their use of the old interface (Use new SkPicture::clone interface - https://codereview.chromium.org/380323002/) > > Committed: https://skia.googlesource.com/skia/+/e372e78223a8ce916d276d6e0420d552fb0267e9 R=mtklein@google.com, reed@google.com TBR=mtklein@google.com, reed@google.com NOTREECHECKS=true NOTRY=true Author: robertphillips@google.com Review URL: https://codereview.chromium.org/386933004
* Add alternate SkPicture::cloneGravatar robertphillips2014-07-10
| | | | | | | | | | | | | | | | This adds an alternate version of SkPicture::clone for two reasons: 1) Chromium uses the SkPicture copy constructor to unpack the pictures from the old-style clone interface (and I would like to remove the copy ctor) 2) This is part of the long term plan to wean Chrome off of cloning. Once pictures are thread safe we will switch the new SkPicture::clone call to just return 'this'. From there it is a small step to removing clone entirely. Note that the two versions of clone() is temporary. Once this is landed (and rolled) I will land a Chrome-side patch to remove their use of the old interface (Use new SkPicture::clone interface - https://codereview.chromium.org/380323002/) R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/381193002
* Cleanup SkPicture* classes a bitGravatar robertphillips2014-07-10
| | | | | | | | | | | | This is an attempt to reduce the number of friends the various SkPicture* classes have. Probably the only controversial part is making getBitmap, getPath, getPicture and getPaint public on SkPictureData (and adding a new initIterator entry point). R=mtklein@google.com, reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/384753004
* 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
* Linear-time implementation of willPlaybackBitmaps(), computed & cachedGravatar tomhudson2014-07-05
| | | | | | | | | | | | | on construction in SkPicture. Unit test. Template trickery thanks to mtklein@. BUG=skia:2702 R=mtklein@google.com, reed@android.com, reed@google.com, tomhudson@google.com, mtklein, reed Author: tomhudson@chromium.org Review URL: https://codereview.chromium.org/366443002
* 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
* 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
* Support serialization in SkRecord-backed SkPictures.Gravatar mtklein2014-06-24
| | | | | | | | | | | Update DM to test SkRecord through SkPictureRecorder API. BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/345553003
* Prune some dead code from SkPicture.cpp.Gravatar mtklein2014-06-24
| | | | | | | | | | | There's no path that makes playback != fPlayback.get() anymore. BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/352643002
* 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
* No one uses SkPicture::swap.Gravatar Mike Klein2014-06-23
| | | | | | | BUG=skia: R=robertphillips@google.com Review URL: https://codereview.chromium.org/349313004
* 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
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-27 18:39:28 +0000