aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkPictureData.h
Commit message (Collapse)AuthorAge
* Make sp variants for SkDataGravatar reed2016-03-11
| | | | Review URL: https://codereview.chromium.org/1779263003
* Style Change: NULL->nullptrGravatar halcanary2015-08-27
| | | | | | DOCS_PREVIEW= https://skia.org/?cl=1316233002 Review URL: https://codereview.chromium.org/1316233002
* Deduplicate typefaces across sub-picturesGravatar mtklein2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Old flow to serialize a picture: 1) serialize picture ops 2) serialize all sub pictures recursively 3) flatten the rest of this picture into a buffer, deduping flattenable factories and typefaces as we go 4) serialize the factories and typefaces 5) serialize the bytes from 3) This allows the data in step 5) to refer to the deduplicated factories and typefaces from step 4). But, each sub picture in step 2) is completely siloed, so they can't dedup with the parent picture or each other. New flow: 1) serialize picture ops 2) flatten the rest of this picture into a buffer, deduping flattenable factories and typefaces as we go 3) dummy-serialize sub pictures into /dev/null, with the effect of adding any new typefaces to our dedup set 4) serialize the factories and typefaces 5) serialize the bytes from 2) 6) serialize all sub pictures recursively, with perfect deduplication because of step 3). Now all typefaces in the top-level picture and all sub pictures recursively should end up deduplicated in the top-level typeface set. Decoding changes are similar: we just thread through the top-level typefaces to the sub pictures. What's convenient / surprising is that this new code correctly reads old pictures if we just have each picture prefer its local typeface set over the top-level one: old pictures always just use their own typefaces, and new pictures always use the top-level ones. BUG=skia:4092 Review URL: https://codereview.chromium.org/1233953004
* change old picture serialization to really handle imagesGravatar reed2015-06-22
| | | | | | BUG=skia:3965 Review URL: https://codereview.chromium.org/1199473002
* Make SkStream *not* ref counted.Gravatar scroggo2015-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkStream is a stateful object, so it does not make sense for it to have multiple owners. Make SkStream inherit directly from SkNoncopyable. Update methods which previously called SkStream::ref() (e.g. SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(), which required the existing owners to call SkStream::unref()) to take ownership of their SkStream parameters and delete when done (including on failure). Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some cases this means heap allocating streams that were previously stack allocated. Respect ownership rules of SkTypeface::CreateFromStream() and SkImageDecoder::buildTileIndex(). Update the comments for exceptional methods which do not affect the ownership of their SkStream parameters (e.g. SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be explicit about ownership. Remove test_stream_life, which tested that buildTileIndex() behaved correctly when SkStream was a ref counted object. The test does not make sense now that it is not. In SkPDFStream, remove the SkMemoryStream member. Instead of using it, create a new SkMemoryStream to pass to fDataStream (which is now an SkAutoTDelete). Make other pdf rasterizers behave like SkPDFDocumentToBitmap. SkPDFDocumentToBitmap delete the SkStream, so do the same in the following pdf rasterizers: SkPopplerRasterizePDF SkNativeRasterizePDF SkNoRasterizePDF Requires a change to Android, which currently treats SkStreams as ref counted objects. Review URL: https://codereview.chromium.org/849103004
* Replace EncodeBitmap with an interface.Gravatar scroggo2014-12-11
| | | | | | | | | | | | | | Gives more flexibility to the caller to decide whether to use the encoded data returned by refEncodedData(). Provides an implementation that supports the old version of SkPicture::serialize(). TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely BUG=skia:3190 Review URL: https://codereview.chromium.org/784643002
* Revert of Replace EncodeBitmap with an interface. (patchset #12 id:210001 of ↵Gravatar scroggo2014-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/784643002/) Reason for revert: Failing serialization tasks in DM: http://build.chromium.org/p/client.skia/builders/Test-Win8-ShuttleA-GTX660-x86-Debug/builds/352/steps/dm/logs/stdio Original issue's description: > Replace EncodeBitmap with an interface. > > Gives more flexibility to the caller to decide whether to use the > encoded data returned by refEncodedData(). > > Provides an implementation that supports the old version of > SkPicture::serialize(). > > TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely > > BUG=skia:3190 > > Committed: https://skia.googlesource.com/skia/+/0c4aba6edb9900c597359dfa49d3ce4a41bc5dd1 > > Committed: https://skia.googlesource.com/skia/+/02b217f80b01a7dda8493422e5257c36a9ce8464 TBR=reed@google.com,rmistry@google.com NOTREECHECKS=true NOTRY=true BUG=skia:3190 Review URL: https://codereview.chromium.org/783393004
* Replace EncodeBitmap with an interface.Gravatar scroggo2014-12-09
| | | | | | | | | | | | | | | | Gives more flexibility to the caller to decide whether to use the encoded data returned by refEncodedData(). Provides an implementation that supports the old version of SkPicture::serialize(). TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely BUG=skia:3190 Committed: https://skia.googlesource.com/skia/+/0c4aba6edb9900c597359dfa49d3ce4a41bc5dd1 Review URL: https://codereview.chromium.org/784643002
* Revert of Replace EncodeBitmap with an interface. (patchset #11 id:190001 of ↵Gravatar robertphillips2014-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/784643002/) Reason for revert: Compilation is failing on some bots Original issue's description: > Replace EncodeBitmap with an interface. > > Gives more flexibility to the caller to decide whether to use the > encoded data returned by refEncodedData(). > > Provides an implementation that supports the old version of > SkPicture::serialize(). > > TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely > > BUG=skia:3190 > > Committed: https://skia.googlesource.com/skia/+/0c4aba6edb9900c597359dfa49d3ce4a41bc5dd1 TBR=reed@google.com,scroggo@google.com NOTREECHECKS=true NOTRY=true BUG=skia:3190 Review URL: https://codereview.chromium.org/787833002
* Replace EncodeBitmap with an interface.Gravatar scroggo2014-12-09
| | | | | | | | | | | | | | Gives more flexibility to the caller to decide whether to use the encoded data returned by refEncodedData(). Provides an implementation that supports the old version of SkPicture::serialize(). TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely BUG=skia:3190 Review URL: https://codereview.chromium.org/784643002
* Followup: remove unnecessary SkTRefArrayGravatar mtklein2014-11-12
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/719113004
* More cleanup: streamline paths and bitmaps.Gravatar mtklein2014-11-12
| | | | | | | | SkBitmapHeap is still used---now exclusively---by pipe. BUG=skia: Review URL: https://codereview.chromium.org/715413002
* 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
* 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
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* 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
* 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
* 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
* Add layer counting to SkPictureRecordGravatar robertphillips2014-08-12
| | | | | | | | | | | | This will be used for a SkPicture::suitableForOptimization entry point. Committed: https://skia.googlesource.com/skia/+/4a2b2e8ed2e35171bf98bad68a69daaced11ec7c R=bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/464433002
* Revert of Add layer counting to SkPictureRecord ↵Gravatar mtklein2014-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/464433002/) Reason for revert: DM's all segfaulty http://108.170.220.120:10117/builders/Test-Mac10.7-MacMini4.1-GeForce320M-x86_64-Debug/builds/3866/steps/RunDM/logs/stdio Original issue's description: > Add layer counting to SkPictureRecord > > This will be used for a SkPicture::suitableForOptimization entry point. > > Committed: https://skia.googlesource.com/skia/+/4a2b2e8ed2e35171bf98bad68a69daaced11ec7c R=bsalomon@google.com, robertphillips@google.com TBR=bsalomon@google.com, robertphillips@google.com NOTREECHECKS=true NOTRY=true Author: mtklein@google.com Review URL: https://codereview.chromium.org/452673003
* Add layer counting to SkPictureRecordGravatar robertphillips2014-08-11
| | | | | | | | | | This will be used for a SkPicture::suitableForOptimization entry point. R=bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/464433002
* Cleaning up SkPicture-related classesGravatar robertphillips2014-08-11
| | | | | | | | R=mtklein@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/459043002
* Moved SkPictureContentInfo into its own file. It now tracks the number of skiaGravatar hendrikw2014-08-08
| | | | | | | | | | | | | | | | | operations (maybe, I'm not 100% sure I'm doing this right yet) and the number of text draws. I also moved some of the gpu logic out of SkPictureRecord and into SkPictureContentInfo, http://code.google.com/p/chromium/issues/detail?id=396908 http://code.google.com/p/chromium/issues/detail?id=397198 http://code.google.com/p/chromium/issues/detail?id=399728 BUG=396908 R=nduca@chromium.org, mtklein@chromium.org, robertphillips@google.com, mtklein@google.com Author: hendrikw@chromium.org Review URL: https://codereview.chromium.org/435093003
* 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
* Re-add friend Chrome requiresGravatar robertphillips2014-07-10
| | | | | | | | | R=jcgregorio@google.com TBR=jcgregorio@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/381963002
* 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 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 06:39:59 +0000