This CL removes the hardcoded mappings of FallbackScripts to
a particular font file and replaces it with a dynamic mechanism
that takes a style and representative character code for a given
FallbackScript class and returns the most appropriate SkTypeface
that contains that character code.
Review URL: https://codereview.appspot.com/6197074
git-svn-id: http://skia.googlecode.com/svn/trunk@4111 2bbb7eff-a529-9590-31e7-b0007b416f81
This patch adds minimal support for dynamic ARM NEON support,
i.e. the ability to probe the CPU at runtime for NEON and
provide alternate code paths when it is available.
- Add include/core/SkUtilsArm.h, which declares a few helper
macros (e.g. SK_NEON_ARM_IS_DYNAMIC), plus the handy
function 'sk_cpu_arm_has_neon()' which returns true if
the target CPU supports the ARM NEON instruction set.
Note that the header is in include/core/ because it will
have to be included from NEON-specific code under src/code/
It would probably be more logical to put it under include/opts/
instead, but this would require moving all the NEON-specific
stuff under src/code/ into src/opts/, which is not trivial
due to the way the code is currently architected.
- Add src/core/SkUtilsArm.cpp which implements
'sk_cpu_arm_has_neon' for ARM-based Linux systems, only
when SK_NEON_ARM_IS_DYNAMIC is true.
(For other cases, 'sk_cpu_arm_has_neon' is an inline function
that returns a constant 'true' or 'false' value).
There is no user-level accessible CPUID instruction on ARM,
so do all CPU feature probing by parsing /proc/cpuinfo.
This is Linux-specific.
For Debug build types, the CPU probing result is printed
to the Android log (or Linux command-line) for easier
debugging.
- Create a new 'opts_neon' target (static library) which shall
contain all the NEON-specific code paths for the library.
This is necessary because -mfpu=neon impacts also non-scalar
code. Just like with -mssse3 on x86, we can't build the rest
of the library with this flag.
Note that for now, we only include memset16_neon and
memset32_neon in this library.
- Modify opts_check_arm.cpp to implement SK_ARM_NEON_IS_DYNAMIC
properly.
Compared to a 'xoom' build, the only difference is the use of
NEON-optimized memset16/32 functions. Later patches will move
more NEON-specific code paths to 'opts_neon'.
Review URL: https://codereview.appspot.com/6247058
git-svn-id: http://skia.googlecode.com/svn/trunk@4069 2bbb7eff-a529-9590-31e7-b0007b416f81
or stroke parameters for a path.
Today, the patheffect only sees if the caller was going to stroke or fill, and
if stroke, it just sees the width. With this change, the effect can see all of the
related parameters (e.g. cap/join/miter). No other change is intended at this
time.
After this change, I hope to use this additional data to allow SkDashPathEffect
to, at times, apply the stroke as part of its effect, which may be much more
efficient than first dashing, and then reading that and stroking it.
Most of these files changed just because of the new parameter to filterPath. The
key changes are in SkPathEffect.[h,cpp], SkPaint.cpp and SkScalerContext.cpp
Review URL: https://codereview.appspot.com/6250051
git-svn-id: http://skia.googlecode.com/svn/trunk@4048 2bbb7eff-a529-9590-31e7-b0007b416f81
or stroke parameters for a path.
Today, the patheffect only sees if the caller was going to stroke or fill, and if
stroke, it just sees the width. With this change, the effect can see all of the
related parameters (e.g. cap/join/miter). No other change is intended at this
time.
After this change, I hope to use this additional data to allow SkDashPathEffect
to, at times, apply the stroke as part of its effect, which may be much more
efficient than first dashing, and then reading that and stroking it.
Most of these files changed just because of the new parameter to filterPath. The
key changes are in SkPathEffect.[h,cpp], SkPaint.cpp and SkScalerContext.cpp
Review URL: https://codereview.appspot.com/6249050
git-svn-id: http://skia.googlecode.com/svn/trunk@4046 2bbb7eff-a529-9590-31e7-b0007b416f81
pixelref subclasses want a mutex to guard their lock/unlock virtuals, and (b)
most subclasses use the same mutex for *all* of their instances, even when there
is no explicit need to guard modifying one instances with another.
When we try drawing bitmaps from multiple threads, we are seeing a lot of slow-
down from these mutexes. This CL has two changes to try to speed things up.
1. Add setPreLocked(), for pixelrefs who never need the onLockPixels
virtual to be called. This speeds up those subclasses in multithreaded environs
as it avoids the mutex lock all together (e.g. SkMallocPixelRef).
2. Add setMutex() to allow a subclass to change the mutex choice. ashmem wants
this, since its unflattening constructor cannot pass down the null, it needs
to cleanup afterwards.
Review URL: https://codereview.appspot.com/6199075
git-svn-id: http://skia.googlecode.com/svn/trunk@3985 2bbb7eff-a529-9590-31e7-b0007b416f81
between these two procs. The fixes was in two parts:
1. Just don't draw bitmaps larger than 64K-1 in width or height, since we
can't represent those coordinates in our transport format (yet).
2. Perform an unsigned shift during the calculation, so we don't get
sign-extension bleed when packing the two values (X,Y) into our 32bit
slot.
Review URL: https://codereview.appspot.com/6173046
git-svn-id: http://skia.googlecode.com/svn/trunk@3836 2bbb7eff-a529-9590-31e7-b0007b416f81
region (normal mode) or does a quick-return if the result will be non-empty
(called for predicates like contains() and intersects()).
git-svn-id: http://skia.googlecode.com/svn/trunk@3791 2bbb7eff-a529-9590-31e7-b0007b416f81
