SDL isn't an OS anyway, it's just a library views can use. Remaining
support for Brew was removed some time ago, and there are currently
no uses of SK_BUILD_FOR_PALM.
Review URL: https://codereview.chromium.org/1268573002
This hasn't been tested for years, and no one currently knows when it
last worked (if ever). It is doubtful that any of the remaining logic
would even make sense with a modern version of Embedded Compact 2013.
Review URL: https://codereview.chromium.org/1260453008
The current include-what-you-use with current clang is much less
noisy and more useful than it has been in the past. This change
introduces a few IWYU directives (which are helpful documentation for
humans as well) and fixes a few sets of includes.
Review URL: https://codereview.chromium.org/1207893002
To make this work, we tag their pixelrefs as temporarily immutable, allowing
ourselves to restore the pixels to mutability only when the image drops away.
This should allow us to wobble back and forth between writing to the Surface
and reading from the Image without a COW, with the Surface seeing mutable
pixels and the Image seeing immutable pixels.
The big idea is, Image doesn't need forever-immutable pixels, it just needs
pixels that are immutable as long as it's alive.
BUG=skia:
patch from issue 804523002 at patchset 40001 (http://crrev.com/804523002#ps40001)
Review URL: https://codereview.chromium.org/1254383006
This reverts commit d12e6ffa5c.
Our Chrome roll canaries are failing with the dreaded
Ninja-says-there's-more-work-to-do message. I will break this up
smaller (if possible) and try again tomorrow.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1258293004 .
This is a contract change for SkPath::getBounds(), which formally was defined to return 0,0,0,0 for a 1-point path, regardless of the coordinates of that point. This seems wacky/inconsistent, and was causing other bugs (incorrect bounds) when this was unioned with other rects.
Does anyone remember why we defined it this way?
BUG=513799
Review URL: https://codereview.chromium.org/1261773002
SkSurface_Raster snapshots do not lock their backing bitmaps when the
pixel ref is shared - they only lock on deep-copy.
But since for raster surfaces the pixels are always in memory, I think
it would be OK to also lock in the former case.
This allows for optimized (zero-copy) reads of raster surface snapshot
data.
R=reed@google.com
Review URL: https://codereview.chromium.org/1256993002
Improves max relative error from 0.00175126 to 0.000650197.
Also add unit tests to check error bounds.
BUG=chromium:511458
Review URL: https://codereview.chromium.org/1251423002
Tidy up a little while I'm in here:
1) SIMD headers are now included by SkTypes.h as appropriate.
2) _mm_cvtss_f32() is pithier and generates the same code.
Looks like this is the only code checking for SSE wrong. After this CL:
~/skia (sse) $ git grep __SSE
include/core/SkPreConfig.h: #if defined(__SSE4_2__)
include/core/SkPreConfig.h: #elif defined(__SSE4_1__)
include/core/SkPreConfig.h: #elif defined(__SSE3__)
include/core/SkPreConfig.h: #elif defined(__SSE2__)
every other check is in SkPreConfig.h where it belongs.
This is going to affect some GMs subtly on Windows.
BUG=chromium:511458
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1248503004
This is split off of https://codereview.chromium.org/1225923010/ (Start tightening correspondence betweeen GrDrawContext and GrRenderTarget). It:
fixes some style nits
replaces some passing of GrContext with GrTextureProvider & GrDrawContext
does a bit of the finer grained creation of GrDrawContexts
Review URL: https://codereview.chromium.org/1245183002
Visual Studio 2015 has additional warnings around noexcept and
disabling exceptions, which can be worked around with the
(undocumented) _HAS_EXCEPTIONS macro.
Visual Studio 2013 and 2015 have roundf in math.h, so use it to
avoid extra work and casts.
We avoid using cmath, as it undefs isfinite on gcc, but Visual Studio
2015 no longer provides overloads of copysign from math.h (which is
actually correct). As a result, use copysignf (which is available in
math.h in 2013 and 2015) directly.
Review URL: https://codereview.chromium.org/1244173005
This deduplicates a few pieces of code:
- we end up with one copy of each xfer32() driver loop instead of one per xfermode;
- we end up with two* copies of each xfermode implementation instead of ten**.
* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.
This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
TBR=reed@google.com
No public API changes.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon-Trybot
Review URL: https://codereview.chromium.org/1242743004
Reason for revert:
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon/builds/1168/steps/build%20most/logs/stdio
Original issue's description:
> De-templatize Sk4pxXfermode code a bit.
>
> This deduplicates a few pieces of code:
> - we end up with one copy of each xfer32() driver loop instead of one per xfermode;
> - we end up with two* copies of each xfermode implementation instead of ten**.
>
> * For a given Mode: Mode() itself and xfer_aa<Mode>().
> ** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
>
> This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
>
> If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
>
> Performance is affected in proportion to the original xfermode speed:
> fast modes like Plus take the largest proportional hit, and slow modes
> like HardLight or SoftLight see essentially no hit at all.
>
> This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
>
> For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
>
> TBR=reed@google.com
> No public API changes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49daTBR=msarett@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1245273005
This deduplicates a few pieces of code:
- we end up with one copy of each xfer32() driver loop instead of one per xfermode;
- we end up with two* copies of each xfermode implementation instead of ten**.
* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.
This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
TBR=reed@google.com
No public API changes.
BUG=skia:
Review URL: https://codereview.chromium.org/1242743004
This change is motivated by a recent switch in how chromium handles
<video> color spaces, making rec709 more commonly used. This will
allow video -> canvas copies to take the fast GPU path when we're using
709, just as we do with 601 and jpeg.
Chromium-side change: https://codereview.chromium.org/1236313002
Review URL: https://codereview.chromium.org/1241723005
Motivation:
- perf win for clients that overwrite the surface after a snapshot.
- may allow us to eliminate SkDeferredCanvas, as this was its primary advantage.
BUG=skia:
Review URL: https://codereview.chromium.org/1236023004
The new test is disabled by default, as it's quite slow.
We can run it if we suspect problems by passing -x to DM.
This test would have been failing before the bug fix, and now is passing.
Assuming the Priv on the end means it's not considered public API...
TBR=reed@google.com
BUG=skia:4052
Review URL: https://codereview.chromium.org/1228333003
and are treated as convex when they are not.
Allow the SkPath::Iter to leave degenerate path
segments unmolested by passing an additional exact
bool to next().
Treat any non-zero length as significant in addPt().
R=reed@google.com,robertphillips@google.com
BUG=493450
Review URL: https://codereview.chromium.org/1228383002
The error log is as follows:
../../third_party/skia/include/core/SkSpinlock.h:24: error: undefined reference to 'SkPODSpinlock::contendedAcquire()'
collect2: error: ld returned 1 exit status
[mtklein added below here]
Despite the presence in include/ and the added SK_API, this file is not part of Skia's public API... it's just used by files which are.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1229003004
The proportion of time spent doing useful work is well over 99% in acquire(),
so outlining it doesn't hurt speed at all, and makes it much easier to pick out
on a profile.
It'd be about 50/50 work/overhead if we outlined the extremely-cheap release().
I also tried outlining some SkRefCnt methods with similar mixed results.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1212253013
Follow up to the split between SkImageGenerator and SkCodec. Now that
SkCodec does not inherit from SkImageGenerator, SkImageGenerator no
longer needs Options or Result, which were added for SkCodec. Remove
them, but keep them behind a flag, since Chromium has its own
subclasses of SkImageGenerator which assume the old signature for
onGetPixels.
Review URL: https://codereview.chromium.org/1226023003
For some users of SkPictureRecorder, the cull rect is more efficiently
determined while drawing is in progress, rather than when recording starts.
The existing API requires the cull rect at start time, even though the
information is not used for any culling purpose until the end of recording.
This patch provides a means to reset the cull rect when recording ends,
allowing users to update the rect based on information learned during
drawing and for the new rect to be used as the culling bound. A valid
bound is still required on the beginRecording call because
it sizes the underlying canvas and sets the aspect ratio for any bounding
box hierarchy. The bounding box factory can also be specified and parameters
that control SkPicture creation.
R=mtklein, reed1
BUG=skia:3919
Review URL: https://codereview.chromium.org/1178673007
