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 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
The divide by w can generate slightly erroneous results even
for t == 0 or t == 1. The error in turn defeats detecting
a point in common for a pair of curves that travel in
opposite directions.
Instead, special case endpoints when the t is 0 or 1.
TBR=reed@google.com
BUG=514118
Review URL: https://codereview.chromium.org/1259513004
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
This allows codecs that support subsets natively (i.e. WEBP) to do so.
Add a field on SkCodec::Options representing the subset.
Add a method on SkCodec to find a valid subset which approximately
matches a desired subset.
Implement subset decodes in SkWebpCodec.
Add a test in DM for decoding subsets.
Notice that we only start on even boundaries. This is due to the
way libwebp's API works. SkWEBPImageDecoder does not take this into
account, which results in visual artifacts.
FIXME: Subsets with scaling are not pixel identical, but close. (This
may be fine, though - they are not perceptually different. We'll just
need to mark another set of images in gold as valid, once
https://skbug.com/4038 is fixed, so we can tests scaled webp without
generating new images on each run.)
Review URL: https://codereview.chromium.org/1240143002
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
While investigating my bug (skia:4052) I saw this TODO and figured
it'd make me feel better about an otherwise unsuccessful investigation.
This speeds up HardLight and Overlay (same code) by about 15% with SSE, mostly
by rewriting the logic from 1 cheap comparison and 2 expensive div255() calls
to 2 cheap comparisons and 1 expensive div255().
NEON speeds up by a more modest ~3%.
BUG=skia:
Review URL: https://codereview.chromium.org/1230663005
When only the left or top edge of a crop rect is given, the
right and bottom should be computed based on the incoming width
and height, not based on the crop rect's width & height. This
complies more accurately with SVG semantics.
BUG=240827
Review URL: https://codereview.chromium.org/1232873002
Make getScanlineDecoder return a new object each time, which is
owned by the caller, and independent from any existing scanline
decoders and the SkCodec itself.
Since the SkCodec already contains the entire state machine, and it
is used by the scanline decoders, simply create a new SkCodec which
is now owned by the scanline decoder.
Move code that cleans up after using a scanline decoder into its
destructor
One side effect is that creating the first scanline decoder requires
a duplication of the stream and re-reading the header. (With some
more complexity/changes, we could pass the state machine to the
scanline decoder and make the SkCodec recreate its own state machine
instead.) The typical client of the scanline decoder (region decoder)
uses an SkMemoryStream, so the duplication is cheap, although we
should consider the extra time to reread the header/recreate the state
machine. (If/when we use the scanline decoder for other purposes,
where the stream may not be cheaply duplicated, we should consider
passing the state machine.)
One (intended) result of this change is that a client can create a
new scanline decoder in a new thread, and decode different pieces of
the image simultaneously.
In SkPngCodec::decodePalette, use fBitDepth rather than a parameter.
Review URL: https://codereview.chromium.org/1230033004
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
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
DEPS:
Update to pull v0.4.3 of libwebp from upstream
gyp/libwebp.gyp:
Add new files, as referenced by the gyp file used by Chromium.
resource/tests:
Add regression tests for particular images.
BUG=skia:3442
BUG=skia:3315
BUG=skia:3429
Review URL: https://codereview.chromium.org/1178013008
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
to compute the overlapping ranges and combine the winding
into a single destination.
This computes coincidence more rigorously, fixing the
edge cases exposed by this bug.
Also, add the ability to debug and dump pathop structures
from the coincident context.
TBR=reed@google.com
BUG=skia:3651
Review URL: https://codereview.chromium.org/1182493015
the bottom of the image. In our code before this patch,
this would result in cleanup code in onFinish() never being
called.
We can allow subclasses to take ownership of the
SkScanlineDecoder in order to make sure that it is
finished/deleted before deleting the decode manager.
BUG=skia:
Review URL: https://codereview.chromium.org/1212593003
This patch ensures that when inverting a SkMatrix44, we handle small
floats properly. When inverted these can cause infinite values, but
still evaluate to true in an if condition.
BUG=chromium:498516
Review URL: https://codereview.chromium.org/1209763002
A path can be non-empty but become empty when it is simplified.
For instance, a path with the same rectangle, twice, with opposite
windings.
No contours are created for empty paths, so don't try to
fix their winding direction.
Additionally, check for a NULL coincidence since the
OpBuilder assumes that no concidence edges can be present
after the paths are simplified. This code should not get
called, but it's worth the future-proofing to check.
R=fmalita@chromium.org
BUG=502792
Review URL: https://codereview.chromium.org/1218863005
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
There are a number of files with 'FontConfig' in their names which
just have to do with font configuration, but nothing to do with
the FontConfig project or even with each other. This clarifies
that these files deal with parsing for the Android font manager.
Review URL: https://codereview.chromium.org/1200103008
Start moving to a world where everyone provides surface properties.
Most notably this exposes a portion of SkSurfaceProps to the C API.
BUG=skia:3934
Review URL: https://codereview.chromium.org/1195003003
This CL continues cleaning up Skia's usage of SkSurfaceProps. It:
Removes the duplicate SkSurfaceProps object from SkImageFilter::Proxy.
Removes a dispreferred ctor from SkCanvas
Removes the initForRootLayer entry point from SkDevice (since the root device and the canvas should always have the same pixel geometry now).
Review URL: https://codereview.chromium.org/1201983006
Mostly this is about ergonomics, making it easier to do good operations and hard / impossible to do bad ones.
- SkAlpha / SkPMColor constructors become static factories.
- Remove div255TruncNarrow(), rename div255RoundNarrow() to div255(). In practice we always want to round, and the narrowing to 8-bit is contextually obvious.
- Rename fastMulDiv255Round() approxMulDiv255() to stress it's approximate-ness over its speed. Drop Round for the same reason as above... we should always round.
- Add operator overloads so we don't have to keep throwing in seemingly-random Sk4px() or Sk4px::Wide() casts.
- use operator*() for 8-bit x 8-bit -> 16-bit math. It's always what we want, and there's generally no 8x8->8 alternative.
- MapFoo can take a const Func&. Don't think it makes a big difference, but nice to do.
BUG=skia:
Review URL: https://codereview.chromium.org/1202013002
This CL starts the process of pushing kLegacyFontHost_InitType-type SkSurfaceProps up the call stack and out of Skia. It:
Gets rid of the default SkBaseDevice ctor. This means everyone has to always hand an explicit SkSurfaceProps to it.
It makes public the SkBitmapDevice creation methods that require SkSurfaceProps.
Removes (in Skia's code base) all SkBitmapDevice ctor calls w/o SkSurfaceProps.
Makes the "recording" canvases (e.g., pdf, svg, xps) explicitly not use kLegacyFontHost_InitType.
Replicates the creating canvas/device's flags on saveLayer devices
BUG=skia:3934
Review URL: https://codereview.chromium.org/1204433002
sk_inv_determinant has a guard that the determinant can't get too big so this CL only checks if the determinant gets too small.
BUG=492263
Review URL: https://codereview.chromium.org/1188433011
Based on SkImageDecoder_libwebp.
TODO:
Support YUV? (Longer term - may influence our API for SkImageGenerator)
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044433002
When calling SkRegion::writeToMemory(NULL), it should return the same
number of bytes that it writes when calling
SkRegion::writeToMemory(buffer). Add a test to confirm this.
BUG=b/21271229
Review URL: https://codereview.chromium.org/1188293002
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
This fix is necessary to correctly propagate invalidations that
are external to skia. For example, when drawing video or WebGL
into a 2D canvas in Chrome, with mipmaps enabled.
BUG=crbug.com/498356
TEST=GrTextureMipMapInvalidationTest
Review URL: https://codereview.chromium.org/1177843007
Brings in the following functionality:
ARB_draw_instanced
ARB_instanced_arrays
NV_bindless_texture
EXT_direct_state_access
KHR_debug
Also cleans up some of the NVPR extension loading.
BUG=skia:
Review URL: https://codereview.chromium.org/1185573003
Adds a new FBO type kStencil_MSFBOType that is selected whenever
NV_framebuffer_mixed_samples extension is available. In this new
FBO type a non-msaa color buffer is created with a multisampled
stencil buffer attachment.
Replaces numSamples() with separate numColorSamples and numStencilSamples
methods in RenderTarget.
In mixed samples mode non-MSAA codepaths are used to draw simple shapes,
while NVPR-rendered paths and text are rendered with a multisampled
stencil.
BUG=skia:3177
Review URL: https://codereview.chromium.org/1001503002
- input param to addFoo (e.g. addRect), where only CW or CCW are valid)
- output param from computing functions, that sometimes return kUnknown
This CL's intent is to split these into distinct enums/features:
- Direction (public) loses kUnknown, and is only used for input
- FirstDirection (private) is used for computing the first direction we see when analyzing a contour
BUG=skia:
Review URL: https://codereview.chromium.org/1176953002
I haven't figured out a pithy way to have these apply to only classes
originating from SkNx, so let's just remove them. There aren't too
many use cases, and it's not really any less readable without them.
Semantically, this is a no-op.
BUG=skia:
Review URL: https://codereview.chromium.org/1167153002
Tweak some test values to pass with floats.
As expected, this regresses matrix44_setconcat_general by about 2x.
BUG=skia:
Review URL: https://codereview.chromium.org/1169813006
FreeType automatically selects the 'most Unicode' cmap available,
otherwise the default cmap is NULL. When this happens the fallback
should include the 3,0 symbol cmap, as is outlined in the Apple
TrueType documentation. This cmap should effectively be a Unicode
mapping, but exclusively in the private use area.
BUG=skia:1873,chromium:489452
Review URL: https://codereview.chromium.org/1163833003
Long lived SkImageHeap objects currently accumulate refs indefinitely.
This leads to massive memory leaks in the gpu-accelerated 2D canvas
code path. This CL does not implement a general fix for SkGPipe, but
it resolves the leak in SkDeferredCanvas (currently the only user
of SkGPipe) by resetting the image heap when the deferral queue is
flushed. This change also fixes the accounting of bytes allocated
by referenced images in order to trigger flushing heuristics
appropriately.
BUG=crbug.com/494148
Review URL: https://codereview.chromium.org/1145893007
Renames getInvariantOutput to getInvariantBlendedColor on GrXPFactory
and redefines it to not account for coverage conflation. This is the
information that all the callsites actually wanted to know.
BUG=skia:
Review URL: https://codereview.chromium.org/1161273005
Reason for revert:
gfx_unittests (under linux_asan)
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Direct leak of 368 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f7060ebdf in _cairo_image_surface_create_for_pixman_image /build/buildd/cairo-1.10.2/src/cairo-image-surface.c:158@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Indirect leak of 256 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f6c7be26a in _pixman_image_allocate /build/buildd/pixman-0.30.2/build/pixman/../../pixman/pixman-image.c:184@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
I think they are creating a cairo surface, but it has no pixels (zero size?). In this CL, if I see no pixels, I ignore the call-back which is used to free the surface (doh).
Original issue's description:
> Revert[4] of add asserts around results from requestLock
>
> This reverts commit 19663e54c0.
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/df91b73a34e3a306c93a5e320704736255c3d9f0TBR=reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1151063005
Removes the runtime logic used by PorterDuffXferProcessor to decide
blend coeffs and shader outputs, and instead uses a compile-time
constant table of pre-selected blend formulas. Separates out the dst
read fallback into its own XP.
Introduces a new blend strategy for srcCoeff=0 that can apply coverage
with a reverse subtract blend equation instead of dual source
blending.
Adds new macros in GrBlend.h to analyze blend formulas both runtime.
Removes kSetCoverageDrawing_OptFlag and GrSimplifyBlend as they are no
longer used.
Adds a GM that verifies all xfermodes, including arithmetic, with the
color/coverage invariants used by Porter Duff.
Adds a unit test that verifies each Porter Duff formula with every
color/coverage invariant.
Major changes:
* Uses a reverse subtract blend equation for coverage when srcCoeff=0
(clear, dst-out [Sa=1], dst-in, modulate). Platforms that don't
support dual source blending no longer require a dst copy for
dst-in and modulate.
* Sets BlendInfo::fWriteColor to false when the blend does not modify
the dst. GrGLGpu will now use glColorMask instead of blending for
these modes (dst, dst-in [Sa=1], modulate ignored for [Sc=1]).
* Converts all SA blend coeffs to One for opaque inputs, and ISA to
Zero if there is also no coverage. (We keep ISA around when there
is coverage because we use it to tweak alpha for coverage.)
* Abandons solid white optimizations for the sake of simplicity
(screen was the only mode that previous had solid white opts).
Minor differences:
* Inconsequential differences in opt flags (e.g. we now return
kCanTweakAlphaForCoverage_OptFlag even when there is no coverage).
* Src coeffs when the shader outputs 0.
* IS2C vs IS2A when the secondary output is scalar.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/9a70920db22b6309c671f8e5d519bb95570e4414
Review URL: https://codereview.chromium.org/1124373002
