Implement path tight bounds using path ops machinery. This is not
as efficient as it could be; for instance, internally, it creates
a path ops structure more suited to intersection. If this shows
up as a performance bottleneck, it could be improved.
Fix path ops gyp files, which have fallen out of sync with other
tests.
R=mtklein@google.com, bsalomon@google.com
TBR=mtklein
BUG=skia:1712
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/348343002
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
Extract "text align proc" as reusable classes. These classes need to be used
when writing GrTextContext subclasses.
Moves "text align proc" code that is duplicated in SkDraw and
SkBitmapTextContext to SkDrawProcs.h and SkTextMapState.h. This functionality is
also used in the new GrStencilAndCoverTextContext.
Creates new functor classes SkTextAlignProc and SkTextAlignProcScalar which
represent the previous "text align procs".
Moves TextMapState from SkDraw to SkTextMapStateProc and make it similar functor.
The transform should be comparable in speed, as the compiler can and does avoid
the call and eliminate some of the branches.
R=jvanverth@google.com, reed@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/335573002
This CL sets the stage for retracting the SkPicture::kOptimizeForClippedPlayback_RecordingFlag flag
from the public API (more work needs to be done in Blink & Chrome). In the new world the only way
to set this flag (and thus instantiate an SkPicture-derived
class) is by passing a factory to the SkPictureRecorder class. This is to get all clients always using
factories so that we can then change the factory call used (i.e., so the factory just creates a BBH) and
do away with the SkPicture-derived classes.
BUG=skia:2315
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/239703006
git-svn-id: http://skia.googlecode.com/svn/trunk@14221 2bbb7eff-a529-9590-31e7-b0007b416f81
Add SkSmallAllocator, a template for allocating small (as defined by the
instantiation) objects without extra calls to new. Add a helper macro to
make using it simple.
Remove SkTemplatesPriv.h, whose behavior is replaced by SkSmallAllocator.
The old SK_PLACEMENT_NEW had the following drawbacks:
- Easily confused with SkNEW_PLACEMENT.
- Requires passing around lots of void*s along with the storageSize.
- Requires using a separate class for deleting it.
- We had multiple ways Auto objects for deleting in different places.
- It always did a straight heap allocation on Windows, meaning Windows
did not get any advantages from the confusing code.
The new SkSmallAllocator simplifies things:
- It is clear about what it does.
- It takes care of the deletion in one place that is automatically
handled.
Further, the new class can be used to create more than one object. This
is in preparation for BUG=skia:1976, for which we would like to create
a new object without extra heap allocations. The plan is to create both
the blitter and the new object on the stack using the SkSmallAllocator.
Add a new test for SkSmallAllocator.
SkShader.h:
Move the private version of CreateBitmapShader to SkBitmapProcShader
(which already has the implementation) and remove the friend class
(which was only used to call this private function). This allows
SkSmallAllocator to reside in the private src/ directory.
SkBitmapProcShader:
Move CreateBitmapShader and the macro for the storage size here. With
the macro in a (private) header, the (private) headers with function
declarations (which now depend on the storage size used) can see the
macro.
Use SkSmallAllocator in CreateBitmapShader.
Change the macro to kBlitterStorageByteCount, since SkSmallAllocator
takes a byte count as its template parameter.
SkBlitter:
Use the SkSmallAllocator.
Remove Sk3DShader::fKillProc and SkAutoCallProc. Both of their
behaviors have been moved into SkSmallAllocator (SkAutoCallProc was
unnecessary anyway, because the only time we ever used it we also
called detach(), so its auto behavior never happened).
Create the Sk3DShader on the stack, if there's room.
Remove the helper version of Choose, which was unused.
SmallAllocatorTest:
Test for the new class.
The rest:
Use SkSmallAllocator.
BUG=skia:1976
R=reed@google.com, mtklein@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/179343005
git-svn-id: http://skia.googlecode.com/svn/trunk@13696 2bbb7eff-a529-9590-31e7-b0007b416f81
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
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
Make leak counters implemented with SK_DECLARE_INST_COUNT thread-safe.
Enable the leak counting for Debug builds when Skia is built as a
static library. Having SK_DECLARE_INST_COUNT without
SK_DEFINE_INST_COUNT relies on static variables in member functions
declared in the header files. These might be duplicated in the clients
of the library when Skia is built as a dynamic library, producing
incorrect operation.
Protect the instance counter initialization step (initStep) by
using SkOnce.
Makes SkOnce.h part of the public API, since SkInstCnt is public.
Protect the per-class child list shared variable with a per-class mutex.
Changes the behavior in the way that if the child list has been
"cleaned up", it will still try to create subsequent child lists.
BUG=skia:1219
R=robertphillips@google.com, mtklein@google.com, bsalomon@google.com, bungeman@google.com, djsollen@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/99483003
git-svn-id: http://skia.googlecode.com/svn/trunk@13120 2bbb7eff-a529-9590-31e7-b0007b416f81
This works in a way that is similar to SkData.
SkMallocPixelRef::NewWithProc
Motivation: Chrome has a ETC1PixelRef which calls delete[] on the
pixles on destruction. There is no reason for them to almost
duplicate our class, when we can provide them a more flexible
class. Example use:
static void delete_uint8_proc(void* ptr, void*) {
delete[] static_cast<uint8_t>(ptr);
}
SkPixelRef* new_delete_pixref(const SkImageInfo& info,
SkColorTable* ctable) {
size_t rb = info.minRowBytes();
return SkMallocPixelRef::NewWithProc(
info, rb, ctable,
new uint8_t[info.getSafeSize(rb)],
delete_uint8_proc, NULL);
}
SkMallocPixelRef::NewWithData
Motivation: This allows up to eliminate SkDataPixelRef. We
modified SkImage_Raster to use MallocPixelRef rather than
SkDataPixlRef.
Also: Unit tests in tests/MallocPixelRefTest.
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/106883006
git-svn-id: http://skia.googlecode.com/svn/trunk@12861 2bbb7eff-a529-9590-31e7-b0007b416f81
Skia cannot use Chromium's implementation of mutex (Lock) due to static
initializers. However, we would like to be able to use Chromium's
implementation of atomics. This motivates the split of implementation.
Skia's atomic and mutex calls should be inlinable, especially the atomics.
These calls often compile down to very few instructions, and we currently have
the overhead of a function call. This motivates the header implementation.
There is still a desire for the build system to select the implementation, so
the SK_XXX_PLATFORM_H pattern for header files is introduced. This allows the
build system to control which platform specific header files are chosen.
The Chromium side changes (most of which will need to go in before this change
can be found at https://codereview.chromium.org/19477005/ .
The Chromium side changes after this lands can be seen at
https://codereview.chromium.org/98073013 .
Review URL: https://codereview.chromium.org/19808007
git-svn-id: http://skia.googlecode.com/svn/trunk@12738 2bbb7eff-a529-9590-31e7-b0007b416f81
