The only thing the unlock methods were doing was assert their balance.
This removes the unlock methods and renames the lock methods "read".
BUG=skia:
Review URL: https://codereview.chromium.org/719213008
No subclass overrides either method.
This is just warmup. Perf is neutral. The real meat of the time spent
is inside canComputeFastBounds / computeFastBounds, not getting to them.
BUG=skia:
Review URL: https://codereview.chromium.org/772573003
This switches to a new way of doing this, enforcing the caching with the type
recorded rather than having to do it in SkRecorder. Should be more foolproof.
Updated SkPath and SkBitmap's equivalents too. ImmutableBitmap was close,
but using inheritance now makes the rest of the code less weird.
BUG=437511
I'm not sure whether or not this will _fix_ the SkMatrix aspect of that bug.
There may be other SkMatrices that we're racing on. It does cover the obvious
ones, though, and removing the SkTRacy<> wrapper will allow TSAN to show
us any other races.
It turned out to be easier to turn missing optional matrices into I early rather
than late. I figure this should be harmless. Recording and playback perf both
look neutral.
Review URL: https://codereview.chromium.org/773433003
This was needed for pictures before v33, and we're now requiring v35+.
Will follow up with the same for skia/ext/pixel_ref_utils_unittest.cc
BUG=skia:
Review URL: https://codereview.chromium.org/769953002
this just accelerates what would happen on the next beginRecording() call or the destructor. chrome has unittests that break (shaders on the stack) if we hold on to the internals past endRecording().
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/758813002
16 bits are not enough to hold the integral part of fx in
Clamp_S32_opaque_D32_nofilter_DX_shaderproc.
Weirdly, no GM diffs on my desktop.
BUG=skia:3096
Review URL: https://codereview.chromium.org/733163003
Tested with -fsanitize=signed-integer-overflow.
This new assert used to trigger in MipMap unit test.
Don't appear to be any GM diffs.
BUG=skia:
Review URL: https://codereview.chromium.org/729373004
Restores type safety with all the same features.
(Also note, less code: 29 insertions, 50 deletions.)
BUG=skia:
Review URL: https://codereview.chromium.org/746553002
SkNVRefCnt is a variant of SkRefCnt that's Not Virtual, so weighs 4 bytes
instead of 8 or 16. There's only benefit to doing this if the deriving class
does not otherwise need a vtable, e.g. SkPicture.
I've stripped out some cruft from SkPicture, rearranged fields to pack tightly,
and added compile asserts for the sizes of SkPicture, SkRecord, and
SkVarAlloc.
BUG=skia:3144
Review URL: https://codereview.chromium.org/741793002
It makes the code harder to read, and makes Debug and Release SkTDArrays
different sizes. Looks like fData is left over from when debuggers weren't
very good at inspecting data structures.
No API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/739263002
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
- move field declarations together and pack them a little tighter
- get rid of fData
- remove dead code in debugger, including unused SkPicturePlayback subclass
There are now no more long-lived SkPictureData! (Really, there never were,
but now we don't pretend to support them.)
BUG=skia:
No API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/725143002
This CL cleans up the existing violations and enables the
build time check to ensure that we don't regress.
The motiviation behind this change is to allow clients who include
our headers to be able to build with this warning enabled.
Review URL: https://codereview.chromium.org/726923002
