This patch includes a modified version of Chrome's trace_event.h, which provides
tracing macros that can easily integrate into the about://tracing framework.
Currently the macros link to a default implementation of the (narrow) tracing
class SkDefaultEventTracer which does nothing; next step will be to have Chrome
subclass the SkEventTracer with a shim that bolts Skia's trace events to its own,
allowing Skia's trace events to show up in about://tracing.
I've verified that this file builds properly, and when I added a simple scoped
TRACE_EVENT0 to SkCanvas::drawRect, along with some debug prints in the NOP
implementation of tracing, I saw what I expected printed to the screen.
BUG=skia:
R=nduca@chromium.org, reed@google.com, mtklein@google.com, bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/149563004
git-svn-id: http://skia.googlecode.com/svn/trunk@13256 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
There's little benefit to deduping matrices and regions: they're infrequently
used, and doubly infrequently reused. Their use-weighted byte cost is tiny.
There is some downside to deduping matrices and regions. Even when they're not
used, we prepare dictionaries for deduping them for every picture. Each of
these dictionaries costs 160 bytes, so two unused dictionaries make a big chunk
of the ~1100 bytes it takes to allocate an SkPictureRecord. (~330 come from
parent class SkCanvas, 768 from SkPictureRecord itself, here reduced to 448).
One side benefit of not deduping these guys is that the change weighs -140 lines of code.
It may go without saying, but this breaks the picture format.
Testing: out/Debug/tests && out/Debug/dm (which runs all picture modes by default)
BUG=skia:1850
R=reed@google.com, bensong@google.com, robertphillips@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/143883006
git-svn-id: http://skia.googlecode.com/svn/trunk@13149 2bbb7eff-a529-9590-31e7-b0007b416f81
SkBitmap.cpp:
When copyTo calls readPixels, only clone the genID if the resulting
SkPixelRef has the same dimensions as the original. This catches a
bug where copying an SkBitmap representing the subset of an SkPixelRef
(which implements onReadPixels) would result in the copy sharing the
genID. (Thanks to r6710, this case can only happen using setPixelRef,
so the updated GpuBitmapCopyTest checks for that.)
Move some unnecessary NULL checks to asserts.
When copyTo performs a memcpy, only clone the genID if the resulting
SkPixelRef has the same dimensions as the original. This catches a bug
where copying an extracted SkBitmap with the same width as its original
SkPixelRef would incorrectly have the same genID.
Add a comment and assert in deepCopyTo, when cloning the genID, since
that case correctly clones it.
BitmapCopyTest.cpp:
Pull redundant work out of the inner loop (setting up the source bitmaps
and testing extractSubset). Create a new inner loop for extractSubset, to
test copying the result to each different config.
Extract a subset that has the same width as the original, to catch the
bug mentioned above.
Remove the reporter assert which checks for the resulting rowbytes.
Add checks to ensure that copying the extracted subset changes the genID.
GpuBitmapCopyTest:
Create an SkBitmap that shares an existing SkPixelRef, but only represents
a subset. This is to test the first call to cloneGenID in SkBitmap::copyTo.
In this case, the genID should NOT be copied, since only a portion of the
SkPixelRef was copied.
Also test deepCopy on this subset.
TestIndividualCopy now takes a parameter stating whether the genID should
change in the copy. It also does a read back using the appropriate subset.
It no longer differentiates between copyTo and deepCopyTo, since that
distinction was only necessary for copying from/to configs other than 8888
(which are no longer being tested), where copyTo did a read back in 8888 and
then drew the result to the desired config (resulting in an imperfect copy).
BUG=skia:1742
Committed: http://code.google.com/p/skia/source/detail?r=13021R=mtklein@google.com
Review URL: https://codereview.chromium.org/112113005
git-svn-id: http://skia.googlecode.com/svn/trunk@13090 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
This eliminates any dynamic allocation for hash tables that are never used.
This helps SkPicture, where some tables (SkPaint) are almost always used, but
some rarely (SkMatrix) or never (SkRegion).
This also removes the (as yet unimportant) ability for the hash table to
shrink. This makes resizing harder to reason about, so I'd like to leave it
out until we see a need.
BUG=skia:1850
R=tomhudson@chromium.org, reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/136403004
git-svn-id: http://skia.googlecode.com/svn/trunk@13051 2bbb7eff-a529-9590-31e7-b0007b416f81
