Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
This is a baby step toward refactored (and faster in-process) typeface and flattenable factory encoding and decoding. The sooner SkWriteBuffer knows its flags, the better.
Next steps will be to rearrange Sk{Read,Write}Buffer members into disjoint strategies to handle typefaces and flattenable factories: one for in-process, one for cross-process, one when validating.
BUG=skia:
R=reed@google.com, scroggo@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/138803005
git-svn-id: http://skia.googlecode.com/svn/trunk@13253 2bbb7eff-a529-9590-31e7-b0007b416f81
Eliminates SkFlattenable{Read,Write}Buffer, promoting SkOrdered{Read,Write}Buffer
a step each in the hierarchy.
What used to be this:
SkFlattenableWriteBuffer -> SkOrderedWriteBuffer
SkFlattenableReadBuffer -> SkOrderedReadBuffer
SkFlattenableReadBuffer -> SkValidatingReadBuffer
is now
SkWriteBuffer
SkReadBuffer -> SkValidatingReadBuffer
Benefits:
- code is simpler, names are less wordy
- the generic SkFlattenableFooBuffer code in SkPaint was incorrect; removed
- write buffers are completely devirtualized, important for record speed
This refactoring was mostly mechanical. You aren't going to find anything
interesting in files with less than 10 lines changed.
BUG=skia:
R=reed@google.com, scroggo@google.com, djsollen@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/134163010
git-svn-id: http://skia.googlecode.com/svn/trunk@13245 2bbb7eff-a529-9590-31e7-b0007b416f81
This reduces the allocation overhead of a null picture (create, beginRecording(), endRecording) from about 18K to about 1.9K. (There's still lots more to prune.)
SkPictureFlat can exploit the fact that Writer32 is contiguous simplify its memory management. The Writer32 itself becomes the scratch buffer.
Remove lots and lots of arbitrary magic numbers that were size guesses and minimum allocation sizes. Keep your eyes open for the big obvious DUH why we save 16K per picture! (Spoiler alert. It's because that first save we issue in beginRecording() forces the old SkWriter32 to allocate 16K.)
Tests passing, DM passing.
bench --match writer: ~20% faster
null bench_record: ~30% faster
bench_record on buildbot .skps: ~3-6% slower, ranging 25% faster to 20% slower
bench_pictures on buildbot .skps: ~1-2% faster, ranging 13% faster to 28% slower
BUG=skia:1850
R=reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/137433003
git-svn-id: http://skia.googlecode.com/svn/trunk@13073 2bbb7eff-a529-9590-31e7-b0007b416f81
Revert "Revert "PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap.""""""
This reverts commit eabd6b2ed4e494b323c08f32358f45950a0368c3.
BUG=
Review URL: https://codereview.chromium.org/108773003
git-svn-id: http://skia.googlecode.com/svn/trunk@12624 2bbb7eff-a529-9590-31e7-b0007b416f81
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
