aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkRecordDraw.h
Commit message (Collapse)AuthorAge
* wip for drawablesGravatar reed2014-11-18
| | | | | | | | | | | | Idea: 1. in its mutable recording state, keep a table of drawables on the side, and store an index in the record list. 2. In "immediate-mode" draw, just call the clients drawable directly (need access to our private list to turn the stored index into a proc) 3. when we "snap", we replace the list of drawables with a list of (sub) pictures, and then during playback of the snapped picture, we invoke a private drawable which just calls "drawPicture" on the index'd subpicture. Review URL: https://codereview.chromium.org/727363003
* Rename GrAccelData to SkLayerInfo and move it to src/coreGravatar robertphillips2014-11-12
| | | | Review URL: https://codereview.chromium.org/719133002
* Move SkRecordComputeLayers and CollectLayers into SkRecordDraw.cppGravatar robertphillips2014-11-12
| | | | | | Rather then exposing parts of FillBounds (as in Expose FillBounds to allow GrPictureUtils::CollectLayers to be layered on top of it - https://codereview.chromium.org/698643002/), this CL moves CollectLayers into SkRecordDraw.cpp to accomplish the layering. Review URL: https://codereview.chromium.org/716913003
* Add comments to SkRecordDraw to help people follow.Gravatar danakj2014-11-03
| | | | | | | | | | The calls to visit() to execute the SkRecord::Draw::operator() code path is not clear to read, so adding some comments to help other new-comers follow this through to the SkCanvas calls. R=mtklein@chromium.org Review URL: https://codereview.chromium.org/695403003
* 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
* Fix bug in layer hoisting transition to SkRecord backendGravatar robertphillips2014-09-16
| | | | | | | | | | Care must be taken when setting up the initial CTM matrix for partial SkRecord playbacks b.c. all the setMatrix calls will concatenate with the initial matrix (which may be different then the CTM that is required to draw correctly). R=mtklein@google.com, bsalomon@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/549143003
* SkRecordPartialDraw with less code duplicationGravatar mtklein2014-09-02
| | | | | | | | | BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/527423002
* 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
* SkRecord: Strip out cull-skipping and y-only drawPosTextH skipping.Gravatar mtklein2014-08-08
| | | | | | | | | | | | These optimizations are outclassed by a general bounding-box hierarchy, and are just going to make plugging that into SkRecordDraw more complicated. BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/452983002
* 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
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 15:14:40 +0000