aboutsummaryrefslogtreecommitdiffhomepage
path: root/include/core/SkPicture.h
Commit message (Collapse)AuthorAge
* 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
* Reorganize Layer Hoisting codeGravatar robertphillips2014-09-02
| | | | | | | | | | With the new MultiPictureDraw API the GrContext will be performing the layer hoisting (instead of the SkGpuDevice). This CL being moving the layer hoisting functionality to GrLayerHoister rather then dumping it straight into GrContext. R=bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/531733003
* 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
* Switch GPU Optimization code to SkRecordGravatar robertphillips2014-08-27
| | | | | | | | R=mtklein@google.com, bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/504393002
* 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
* SkTextBlob plumbingGravatar fmalita2014-08-26
| | | | | | | | | | | Add SkTextBlob serialization + drawTextBlob() overrides. R=mtklein@google.com, reed@google.com, robertphillips@google.com BUG=269080 Author: fmalita@chromium.org Review URL: https://codereview.chromium.org/499413002
* 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
* Simplify flattening to just write enough to call the ↵Gravatar reed2014-08-21
| | | | | | | | | | | | | | | | | | factory/public-constructor for the class. We want to *not* rely on private constructors, and not rely on calling through the inheritance hierarchy for either flattening or unflattening(CreateProc). Refactoring pattern: 1. guard the existing constructor(readbuffer) with the legacy build-flag 2. If you are a instancable subclass, implement CreateProc(readbuffer) to create a new instances from the buffer params (or return NULL). If you're a shader subclass 1. You must read/write the local matrix if your class accepts that in its factory/constructor, else ignore it. R=robertphillips@google.com, mtklein@google.com, senorblanco@google.com, senorblanco@chromium.org, sugoi@chromium.org Author: reed@google.com Review URL: https://codereview.chromium.org/395603002
* 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
* 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
* Remove SkPaintOptionsAndroidGravatar djsollen2014-08-14
| | | | | | | | | | Committed: https://skia.googlesource.com/skia/+/f32331ffdb5de0440bb337aa7cbdd6f33e9ff23b R=reed@google.com, mtklein@google.com, tomhudson@google.com Author: djsollen@google.com Review URL: https://codereview.chromium.org/447873003
* Revert of Remove SkPaintOptionsAndroid (patchset #5 of ↵Gravatar bsalomon2014-08-13
| | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/447873003/) Reason for revert: Breaks the Chromium build: http://108.170.220.120:10117/builders/Canary-Chrome-Ubuntu13.10-Ninja-x86_64-DRT/builds/2469/steps/BuildContentShell_1/logs/stdio Original issue's description: > Remove SkPaintOptionsAndroid > > Committed: https://skia.googlesource.com/skia/+/f32331ffdb5de0440bb337aa7cbdd6f33e9ff23b R=reed@google.com, mtklein@google.com, tomhudson@google.com, djsollen@google.com TBR=djsollen@google.com, mtklein@google.com, reed@google.com, tomhudson@google.com NOTREECHECKS=true NOTRY=true Author: bsalomon@google.com Review URL: https://codereview.chromium.org/473543004
* Remove SkPaintOptionsAndroidGravatar djsollen2014-08-13
| | | | | | | | R=reed@google.com, mtklein@google.com, tomhudson@google.com Author: djsollen@google.com Review URL: https://codereview.chromium.org/447873003
* 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
* Revert "Remove SkPaintOptionsAndroid"Gravatar Derek Sollenberger2014-08-06
| | | | | | This reverts commit 27fb94999b8eec448423884e1d071e563c4c95d9. Review URL: https://codereview.chromium.org/450513002
* Remove SkPaintOptionsAndroidGravatar Derek Sollenberger2014-08-06
| | | | Review URL: https://codereview.chromium.org/447873003
* Implement a persistent uniqueID-based cache for SkImageFilter.Gravatar senorblanco2014-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a unique ID to SkImageFilter, and use it as part of a persistent cache of image-filtered results. This is used for caching frame-to-frame coherent filters. We also keep track of which filter subtrees do not reference the src input, and use a GenID of zero for the src input in that case. That way, subtrees which are not dependent on the filter input can be cached independently of it. This gives approximately a 4X speedup on letmespellitoutforyou.com/samples/svg/filter_terrain.svg on Z620 and Nexus10. The cache key consists of the uniqueID of the filter, the clip bounds, the CTM and the genID of the input bitmap. Since this does not yet handle the case where the input primitives (and part of the resulting filter tree) are unchanged, we have to keep around the external cache for that painting case. When the work to cache unchanging input primitives is done, the old cache can be removed, and the new UniqueIDCache will be renamed to Cache. R=bsalomon@google.com, mtklein@google.com Author: senorblanco@chromium.org Review URL: https://codereview.chromium.org/414483003
* 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
* Use SkShader's localMat for SkLocalMatrixShader.Gravatar scroggo2014-07-11
| | | | | | | | | | | | Instead of setting SkShader::fLocalMatrix to Identity and storing a separate SkMatrix inside SkLocalMatrixShader, reuse SkShader::fLocalMatrix. R=reed@google.com Author: scroggo@google.com Review URL: https://codereview.chromium.org/386693003
* 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
* 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
* Back off from SkPicture API hardening a bitGravatar Robert Phillips2014-07-08
| | | | | | | | Sigh - Chromium still relies on the old clone functionality TBR=reed@google.com Review URL: https://codereview.chromium.org/371273006
* Harden SkPicture interface a bitGravatar robertphillips2014-07-08
| | | | | | | | | | With the removal of SkTimedPicture we can now make more of SkPicture private. R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/377833007
* 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
* 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
* 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
* 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 SK_SUPPORT_LEGACY_RECORDING_FLAG flagGravatar robertphillips2014-06-12
| | | | | | | | | | | | | | Chromium/Blink should no longer need this flag after: Chromium: Remove use of kUsePathBoundsForClip_RecordingFlag https://codereview.chromium.org/322123002/ Blink: Remove use of kUsePathBoundsForClip_RecordingFlag https://codereview.chromium.org/326953002/ R=mtklein@google.com, scroggo@google.com, reed@google.com, bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/328343002
* 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
* 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
* Remove SkPicture::kUsePathBoundsForClip_RecordingFlagGravatar robertphillips2014-06-09
| | | | | | | | | | The real question is whether we ever want to record a picture without using the path bounds for a conservative (but faster) clip answer? R=reed@google.com, mtklein@google.com, djsollen@google.com, scroggo@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/316143003
* 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
* 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
* Remove legacy picture recordingGravatar robertphillips2014-06-03
| | | | | | | | | | | | This is unblocked now that Android no longer uses the old interface. This is just the first step in cleaning this up. Future CLs will constify SkPicture access in SkCanvas and split up the SkPicture/SkPicturePlayback/SkPictureRecord trio. R=bsalomon@google.com, reed@google.com, mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/313613002
* Add a way for the gpu veto to report back the reason why it said noGravatar commit-bot@chromium.org2014-05-30
| | | | | | | | | | | BUG=2334 R=bsalomon@google.com Author: humper@google.com Review URL: https://codereview.chromium.org/301423002 git-svn-id: http://skia.googlecode.com/svn/trunk@15012 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-10 00:07:52 +0000